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ABSTRACT 

The  Fleet  Area  Control  and  Surveillance  Facility  FACS- 
FAC  located  at  North  Island,  San  Diego,  currently  performs 
its  data  collection,  storage  and  processing  functions 
manually.  Expected  expansion  of  the  scope  of  operations  at 
FACSFAC  will  overwhelm  the  present  system. 

This  thesis  develops  an  ORACLE-based  relational  data- 
base system  for  use  by  FACSFAC.  The  system  consists  of  two 
applications.  In  the  scheduling  application,  inputs  from 
various  sources  are  compiled,  allowing  both  a  powerful  query 
capability  and  the  production  of  a  weekly  schedule  of  ac- 
tivities for  the  facilities  and  personnel  assigned  to  FACS- 
FAC. The  exercise  results  application  provides  an  automated 
method  of  gathering  and  querying  pertinent  tactical  employ- 
ment and  range  utilization  data  for  required  weekly,  monthly 
and  quarterly  reports. 

The  prototype  system  greatly  facilitates  the  storage, 
query  and  reporting  functions  of  the  organization  and  pro- 
motes increased  efficiency  in  day-to-day  operations. 
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I.    INTRODUCTION 

A.    BACKGROUND 

The  Fleet  Area  Control  and  Surveillance  Facility  (FACS- 
FAC )  is  located  aboard  Naval  Air  Station  North  Island,  San 
Diego,  California.  It  is  a  command  of  the  U.S.  Navy  whose 
current  mission  is  to  provide  specialized  antisubmarine 
warfare  ( ASUI )  and  electronic  warfare  (EW)  training  support 
at  the  Southern  California  Offshore  Range  (SCORE)  to  the 
operational  forces  of  the  Commander  in  Chief,  Pacific  Fleet 
(CINCPACFLT ) .  In  executing  its  assigned  mission,  FACSFAC 
schedules  and  operates  the  range,  provides  for  simulated 
and/or  actual  submarine  targets,  monitors  the  performance  of 
units  exercising  on  the  range,  and  collects  and  analyzes 
tactical  data  from  fleet  units  conducting  training  on  the 
range.  When  weapons  and/or  simulated  targets  are  involved, 
FACSFAC  provides  for  the  retrieval  of  those  assets  at  the 
completion  of  the  exercise.  Additionally,  FACSFAC  is  tasked 
with  the  safe  and  orderly  conduct  of  all  exercises  under- 
taken on  the  various  SCORE  ranges. 

The  Southern  California  ASUI  Range  (SOAR)  provides  "an 
instrumented,  three-dimensional,  in-air  and  underwater 
tracking  range"  [Ref.  1 : pg .  1]  for  use  by  west  coast  air, 
surface  and  submarine  commands.  Presently,  the  112  sguare 
mile  range  is  capable  of  simultaneously  tracking  up  to  eight 
surface  and  air  platforms  and  four  in-water  vehicles. 
Planned  upgrades  to  the  range  include  expansion  to  600 
square  miles  in  area,  with  improved  track  resolution  and 
tracking  capability. 

The  EW  range  currently  provides  training  to  west  coast 
surface  ships  through  the  use  of  a  noise  jammer  simulation 
subsystem   and  a  temporary   radar  signal   simulator  (RSS-19) 


[Ref.  1 : pg .  1].  Training  opportunities  for  the  west  coast 
air  communities  are  also  being  explored.  Future  expansion  of 
the  EW  range  capabilities  will  include  threat  radar  simula- 
tion and  participant  response  monitoring.  These  upgrades 
should  benefit  air  participants  and  attract  additional 
surface  units. 

As  SCORE  continues  to  evolve,  additional  ranges  and 
equipment  will  become  available  to  support  training  exer- 
cises in  ASW ,  EW,  Weapons  Impact  Scoring,  No-Drop  Laser 
Scoring  and  Naval  Gunfire  Support  ( NGFS ) .  A  future  integra- 
ted Range  Operations  Center  (ROC)  will  accommodate  a  wide 
range  of  exercise  scenarios  involving  multiple  warfare 
areas  . 

B.    STATEMENT  OF  PROBLEM 

The  proposed  expansion  of  range  size  and  data  collec- 
tion capabilities  will  overwhelm  the  manual  data  handling 
techniques  of  the  current  FACSFAC  management  information 
system.  Not  only  will  the  scheduling  process  became  more 
complicated  with  the  development  of  additional  ranges  and 
the  increased  utilization  of  those  ranges,  but  the  quantity 
of  tactical  data  collected  during  the  exercises  is  expected 
to  double.  Clearly,  the  present  manual  system  cannot  be  ex- 
pected to  cope  with  this  growth.  Lack  of  an  automated  data- 
base causes  an  inordinate  amount  of  time  to  be  spent  manual- 
ly searching  files  for  data  required  for  the  various  re- 
ports. Optional  data  manipulation  functions  are  not  being 
performed  by  the  Program  Engineers  due  to  the  tedium  as- 
sociated with  the  file  searches.  These  optional  functions, 
consisting  mainly  of  tactical  employment  comparisons,  could 
be  of  significant  use  to  the  training  departments  of  the 
client  commands. 


C .    SCOPE 

The  implementation  of  an  automated  database  to  gather 
and  store  schedule  and  exercise  results  data  and  to  create 
an  exercise  schedule  is  just  one  facet  of  the  integrated 
management  information  system  envisioned  by  FACSFAC .  The  ul- 
timate goal  is  the  creation  of  the  Southern  California  Range 
Asset  Management  Network  (SCRAMNET),  comprised  of  worksta- 
tions and  shared  peripherals  to  create  an  integrated  infor- 
mation resources  system  for  the  SCORE.  The  SCRAMNET  will 
consist  of  three  major  components:  database  applications, 
the  hardware/operating  system,  and  tex t /graphics . 

The  database  applications  component,  called  the  South- 
ern California  Range  Asset  Management  Database  (SCRAMBASE), 
is  divided  into  an  Administration  database  (ABASE)  module, 
an  Equipment  database  ( EBASE )  module,  and  an  Operations 
database  ( OBASE )  module. 


OBASE 


SCRAMBASE 


EBASE 


Figure  1.1   SCRAMBASE  Concept 


The  OBASE  module  is  comprised  schedule  and  exercise  data 
necessary  to  create  a  weekly  schedule  and  generate  required 
reports.  The  prototype  system  designed  by  this  study  will 
perform  the  first  three  functions,  and  in  doing  so  will  also 
make  available  all  data  necessary  for  accomplishment  of  the 
fourth . 

In  essence,  two  distinct  but  interrelated  applications 
will  be  created.  The  first  application  will  perform  those 
functions  of  the  Scheduler  related  to  the  gathering  and 
input  of  data  into  a  weekly  facilities  and  personnel  employ- 
ment schedule.  The  final  product  of  this  application  will  be 
a  printed  schedule  of  weekly  activities.  The  second  applica- 
tion will  provide  the  means  for  the  Program  Engineers  and 
Operations  Analysts  to  effect  the  collection  and  storage  of 
data  pertaining  to  the  exercises  conducted  on  the  ranges. 
Although  no  printed  reports  will  be  produced  by  the  proto- 
type system,  all  data  required  for  those  reports  will  be 
stored  in  the  database. 

D.    METHODOLOGY 

Systems  analysis  is  basically  a  three  phase  process  de- 
signed to  gather  and  analyze  facts  pertaining  to  the  exis- 
ting system,  with  the  ultimate  goal  of  improving  that  system 
through  better  procedures  and  techniques. 

During  the  study  phase,  information  is  gathered  rela- 
tive to  the  capabilities  and  deficiencies  of  the  present 
system.  Specific  objectives  critical  in  developing  an  under- 
standing of  the  system  ar&: 


•  Identify  all  knowledge  workers  who  use  or  are  affected 
by  the  current  system. 

•  Identify  the  purpose,  goals,  objectives  and  policies 
of  the  current  information  system,  and  analyze  the 
extent  to  which  the  mission  is  being  achieved. 


Identify  the  information  system  functions  provided  by 
the  current  system  and  analyze  the  extent  to  which 
these  functions  support  the  knowledge  workers  and  the 
mission . 

Separate   the   current   information   system   into   its 
components  and   analyze  how  these   components  interact 
to  provide  the  current  information  resources. 
[Ref.  2:pg.  182] 


The   second  phase   of  systems   analysis  is  that   of  re- 
quirements definition.  The   two  primary  goals  of   this  stage 

are  : 


•  Identification  of  the  objects  the  user  needs  to  track 
and  definition  of  their  structure. 

•  Determination  of  the  functional  components  of  each 
application  that  will  use  the  database.  [Ref.  3 : pg . 
88]  . 


User  requirements  will  be  discussed  in  Chapter  II. 

The  third,  and  final  phase  of  systems  analysis  is  the 
design  phase,  which  consists  of  both  logical  design  (covered 
in  Chapter  III)  and  the  implementation  of  the  system  (dis- 
cussed in  Chapter  IV). 

E.    FEASIBILITY 

1.  Cost 

The  implementation  of  the  prototype  system  de- 
signed by  this  study  will  require  a  minimum  of  additional 
funds.  Equipment  needed  for  the  system  is  presently  on  hand, 
and  the  time  and  effort  required  to  train  system  operators 
is  expected  to  be  negligible.  The  limited  training  require- 
ments are  primarily  due  to  the  users'  existing  knowledge  of 
the  Oracle  database  system,  the  Users'  Manual  and  the  de- 
signed-in  simplicity  of  the  user  interface. 

2.  Technical 

The  only  technical  limitations  imposed  by  the 
prototype  system  are    those  associated   with  the  selection  of 


Professional  ORACLE  as  the  designated  database  management 
system  to  be  employed.  The  system  requirements  for  use  of 
ORACLE  consist  of: 


•  Compaq  386 ,  IBM  PC/AT,  Personal  System/2  Models  50,  60 
and  80,  or  1007.  compatibles. 

•  DOS  3.1  or  later  version,  or  OS/2. 

•  Up  to  6MB  of  local   hard  disk  to  accomodate  all   soft- 
ware components  and  demonstration  databases. 

•  640  KB   of  regular  RAM  plus   896  KB  of  extended   RAM. 
[Ref.  4:pg.  10]. 


The  design,  development,  documentation  and  testing 
of  the  prototype  system  was  done  on  IBM-compatible  AT  machi- 
nes; implementation  and  further  testing  will  be  done  at 
FACSFAC  on  an  IBM  Model  80.  All  system  requirements  listed 
above  ar^  currently  available  at  FACSFAC,  along  with  a 
technical  support  engineer  who  is  intimately  familiar  with 
the  ORACLE  database  management  system. 
3.    Schedule 

The  prototype  system  for  the  0BASE  component  of 
SCRAMBASE  is  being  developed  concurrently  with,  yet  indepen- 
ently  of,  the  other  two  components.  The  latter  impose  no  re- 
strictions on  0BASE  development,  nor  do  they  more  than 
assoc i a t i ve 1 y  depend  on  its  development.  In  that  the  SCRAM- 
NET  plan  is  a  long-term  process,  it  also  imposes  no  schedu- 
ling constraints  on  the  development  of  this  system.  Thus, 
from  the  schedule  standpoint,  feasibility  is  assumed. 


II.    USER  REQUIREMENTS 

The  determination  of  user  needs,  in  terms  of  both  data 
and  functional  requirements,   is  the  second  step   of  systems 
analysis.  First,  in  order  to   understand  better  the  needs  of 
the   FACSFAC   organization,   the  study   phase   examines   its 
current  method  of  data  collection  and  storage. 

A.     PRESENT  SYSTEM 

The  present  system  used  by  FACSFAC  was  seen  as  being 
two  separate,  but  interacting  applications.  Figures  2.1  and 
2.2  graphically  portray  the  two  applications.  In  those 
diagrams,  a  rectangle  represents  a  source/sink,  an  oval 
represents  a  function  being  performed,  an  arrow  shows  the 
flow  of  data  and  information,  and  the  two  parallel  lines 
represent  a  data  bank  or  database. 

The  first  application  consists  of  those  functions 
necessary  for  gathering  and  input  of  various  data  in  order 
to  create  weekly  and  monthly  schedules  of  activities  for 
FACSFAC  facilities  and  personnel  and  DYNACORP  personnel.  The 
scheduler  receives  the  Quarterly  Employment  Schedule  from 
the  Naval  Undersea  Warfare  Engineering  Station  ( NUWES ) 
containing  the  training  needs  of  the  various  client  com- 
munities. He  then  creates  a  monthly  planner  for  internal  use 
only,  and  uses  it  as  a  guide  for  developing  the  upcoming 
weekly  schedules.  Using  the  monthly  planner  and  asset  avail- 
abilities from  NUWES,  the  client  users  and  the  supporting 
commands,  the  scheduler  generates  individual  exercise  events 
linking  FACSFAC  facilities  with  the  training  requirements  of 
the  clients.  FACSFAC  and  DYNACORP  personnel  are  then  matched 
with  the  exercise  events,  and  a  weekly  activities  schedule 
is  thus  created  and  distributed.  Modifications  to  that 


schedule  are    made  as  needed,  based   upon  inputs  from  NUWES, 
the  supporting  commands  and  clients. 


Quarterly  Employment  Schedule 


Create 
Monthly 
Planner 


NUWES 


Weekly 
Schedule 


Monthly 
Planner 


SUPPORTING 
COMMANDS 


USERS 


Weekly 
Schedule, 


Proposed  Changes  to  Schedule 


Figure  2.1   Current  Scheduling  System. 


The  second  application  consists  of  those  activities 
involved  in  collecting  post-exercise  information  for  the 
purpose  of  generating  required  reports  and  performing  ana- 
lyses on  the  tactical  employment  data  gathered  during  the 
exercise.  In  this  application,  the  Program  Engineer  accumu- 
lates tactical  data  during  the  exercise  from  both  personal 
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NAVSEA 


USERS 


PACFLEET 


CO        | 
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Figure  3.2   Current  Exercise  Results  Function. 


observation  and  inputs  from  the  Operations  Analyst,  Opera- 
tions Controller  and  range  Safety  Officer.  These  data  are 
combined  with  data  obtained  from  the  client  users  during  the 
event  debrief  to  create  an  Exercise  Summary  document  which 
is  then  filed,  an  Attack/Exercise  Performance  Evaluation, 
and  a  MK4&  Rapid  Feedback  Firing  Report,  if  applicable.  The 
Operations  Analyst  periodically  accesses  the  filed  documents 
in  order  to  produce  assorted  other  required  reports. 


B.    REQUIREMENTS  DEFINITION 

The  second  stage  of  systems  analysis  is  that  of  re- 
quirements definition,  wherein  the  determination  is  made  as 
to  exactly  what  the  new  system  must  do.  These  requirements 
consist  of  both  the  data  objects  which  must  be  captured  by 
the  system,  and  the  functions  that  the  new  system  must  be 
able  to  perform. 

1-    Data  Requirements 

System  data  requirements  were  determined  through  a 
series  of  interviews  conducted  with  the  prospective  system 
users  and  management  at  FACSFAC .  These  requirements  were 
then  translated  into  objects,  diagrams  and  specifications. 
Appendix  A  contains  object  diagrams,  Appendix  B  the  object 
specifications,  and  Appendix  C  the  definition  and  other  data 
of  each  domain. 

In  keeping  with  the  scope  of  the  project  as  de- 
scribed in  Chapter  I,  the  database  system  for  FASCFAC  is 
envisioned  as  being  two  primary  applications:  schedule  and 
exercise  results.  The  schedule  application  will  store  all 
data  relevant  to  the  schedule,  but  will  not  perform  the 
actual  scheduling.  The  second  application,  referred  to  as 
the  results  application,  will  store  all  the  results  of  an 
particular  event.  In  terms  of  a  time  line,  scheduling  is 
concerned  with  an  event  before  it  occurs,  and  exercise 
results  is  concerned  with  post-event  analysis. 
a.  Schedul e    Appl ication    Objects 

The  schedule  application  stores  the  schedule 
in  an  easily  updatable  form  to  accommodate  the  many  changes 
that  occur  during  the  scheduling  process.  This  is  accom- 
plished by  breaking  the  data  down  into  the  five  entities 
with  which  the  scheduler  normally  works:  the  exercise  event 
itself,  the  brief,  the  users,  the  weapon  and  the  target. 
These  five  entities  are  represented  by  corresponding  objects 
of  the  same  names.   Of   these  five  objects,  the  main  one   is 
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the  EXERCISE  object,  since  it  contains,  directly  or  indi- 
rectly, all  the  other  objects.  This  is  consistent  with  the 
view  of  the  FACSFAC  personnel  who,  in  most  instances,  view 
the  exercise  as  one  entity,  but  at  other  times  see  each 
object  as  separate  entities. 

The  exercise  entity  is  represented  by  the 
EXERCISE  Object  which  uniquely  identifies  an  instance  of  an 
exercise  (referred  to  as  an  event)  by  the  Exercise  Type  and 
Event  Number.  Normally,  the  scheduler  concatenates  these  two 
numbers  to  form  one  event  identifier.  The  Exercise  Type 
indicates  the  specific  type  of  exercise  to  be  run,  such  as  a 
submarine  torpedo  exercise  or  an  S-3  electronic  warfare 
exercise.  This  data  is  important  to  the  database  because 
each  exercise  has  unique  information  storage  requirements. 
For  example,  electronic  warfare  exercises  do  not  require 
weapons  or  targets,  thus  these  objects  need  not  be  recorded 
as  part  of  the  EXERCISE  object.  The  Event  Number  uniquely 
identifies  an  individual  event  within  each  exercise  type. 
This  number  is  a  sequential  number  for  each  exercise  type 
conducted  during  a  given  year.  The  EXERCISE  object  also 
contains  general  scheduling  information  concerning  the 
event,  such  as  date  and  times,  personnel,  and  message  re- 
quirements. Required  exercise  support,  in  the  form  of  target 
and  weapon  recovery  vehicles,  is  also  identified  in  this 
ob j  ec  t . 

The  BRIEF  Object  consists  of  information 
relevant  to  each  briefing.  Normally,  there  is  a  minimum  of 
two  briefs  associated  with  each  event:  a  pre-event  brief  and 
a  post-event  brief.  The  BRIEF  object  is  used  to  create  a 
Weekly  Briefings  Report  to  ensure  not  only  that  briefer 
knows  when  and  where  his  briefings  are  to  be  held,  but  also 
to  allow  others  to  schedule  the  briefing  room  on  an  "as- 
available"  basis.  Each  brief  is  identified  by  its  title. 
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The  TARGET  Object  contains  information  about 
the  target(s)  to  be  used  during  a  given  exercise.  Creating 
this  separate  object  ensures  that  the  correct  target  parame- 
ters are  being  used  for  each  exercise  event.  The  TARGET 
object  also  contains  the  information  needed  to  schedule  the 
target  launch  vehicle(s).  FACSFAC  personnel  view  this  as 
being  a  separate  object,  mainly  to  depict  how  the  infor- 
mation about  the  targets  is  received.  When  the  schedule  is 
finalized,  it  is  sent  to  the  commands  responsible  for  target 
support,  and  targets  are  provided  to  match  the  scheduled 
need.  The  number  and  type  of  targets  needed  for  an  event 
vary  with  the  type  of  exercise  being  conducted  and  the 
number  of  participants  in  a  particular  event.  Thus,  the 
TARGET  object  can  be  multi-valued  within  the  EXERCISE  ob- 
ject. The  TARGET  object  is  identified  by  Exercise  Type, 
Event  Number  and  Target  Designation. 

The  USERS  Object  contains  those  attributes 
describing  the  client  users  of  the  range.  FACSFAC  considers 
this  as  being  an  object  because  each  client  ship  or  squadron 
is  a  unique  entity.  In  this  application,  at  least  one  client 
command  is  associated  with  an  exercise  event  and  the  USERS 
object  describes  those  command  characteristics  relevant  to 
an  event.  Each  exercise  event  may  have  multiple  users,  to 
include  the  target  itself  if  it  is  a  ship  or  submarine.  For 
aircraft  squadrons  the  USER  object  also  includes  the  number 
of  aircraft  from  that  command  participating  in  the  exercise 
event.  The  USERS  object  also  contains  the  multi-valued 
WEAPON  object.  It  is  identified  by  Exercise  Type,  Event 
Number  and  Command  Name. 

The  WEAPON  Object  is  very  similar  to  the 
TARGET  object,  in  that  it  serves  the  function  for  weapons  as 
the  TARGET  object  does  for  targets.  As  the  TARGET  object  is 
multi-valued  within  an  EXERCISE  object,  the  WEAPON  object  is 
multi-valued  within  a   USERS  object,  with  the   normal  number 
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of  weapons  being  two  for  each  participant  in  an  event.  The 
WEAPON  object  is  identified  by  Weapon  Type  and  Command  Name. 
b.  Results    Appl ication    Objects 

The  RESULTS  Object  is  the  main  object  of  the 
exercise  results  application.  It  has  the  same  identifier  as 
the  EXERCISE  object  with  which  it  is  associated.  A  great 
deal  of  the  information  in  the  results  application  is  trans- 
ferred from  the  scheduling  application  as  default  data.  In 
addition  to  other  attributes,  the  RESULTS  object  contains  a 
multi-valued  attribute,  'reason  cancelled'  ,  which  records 
the  reason(s)  why  an  exercise  was  either  partially  or  en- 
tirely cancelled,  and  the  range  utilization  hours  lost  for 
each  given  reason.  The  RESULTS  object  also  contains  all 
other  objects  that  are    part  of  the  Results  application. 

The  PLATFORM  Object  stores  information  about 
the  individual  unit  that  conducted  an  attack.  The  attacking 
unit  can  be  either  a  ship,  an  aircraft  or  a  submarine. 
Additionally,  a  unit  may  conduct  multiple  attacks  on  a 
target  during  an  event.  The  PLATFORM  object  records  usage  of 
expendable  ordnance  (sonobuoys)  and  reasons  that  scheduled 
weapon  drops  were  not  made.  This  object  is  identified  by 
Exercise  Type,  Event  Number,  Command  Name  and  Side  Number. 

The  ATTACK  Object,  contained  within  the 
PLATFORM  object,  is  the  heart  of  the  results  application.  It 
records  all  information  associated  with  each  attack  instance 
occurring  for  a  given  platform  during  a  particular  event.  An 
instance  of  attack  can  be  real,  in  which  an  exercise  torpedo 
is  actually  expended,  or  simulated.  The  ATTACK  object  also 
records  how  well  the  platform  performed  in  carrying  out  its 
attack(s).  The  information  stored  can  be  used  later  to 
evaluate  the  tactical  proficiency  of  the  platform,  sguadron 
and  community.  An  attack  is  uniguely  identified  by  a  time  of 
fire  and  the  associated  platform  conducting  the  attack.  Data 
recorded  in  each   attack  instance   includes  the  accuracy   of 
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the  platform's  solution  at  the  time  of  the  attack,  the 
tactical  employment  of  the  platform  at  the  time  of  attack, 
and  whether  or  not  the  attack  was  successful.  The  ATTACK 
object  also  contains  the  multi-valued  object  WEAPON  RESULTS. 

The  WEAPON  RESULTS  Object  contains  informa- 
tion pertaining  to  weapon  performance  and  recovery,  and 
individual  instances  are  identified  by  the  type  (mk)  and 
serial  number  of  the  weapon.  The  one  WEAPON  RESULTS  attrib- 
ute relevant  to  the  ATTACK  object  is  'torpedo  performance'. 
Should  an  exercise  torpedo  malfunction,  the  platform  con- 
ducting the  attack  cannot  be  held  responsible  for  the  weapon 
missing  the  target.  Thus,  the  torpedo's  performance  must  be 
recorded  in  the  ATTACK  object.  The  WEAPON  RESULTS  object 
also  contains  the  LOST  object. 

The  TARGET  RESULTS  Object  records  data  about 
the  target  used  during  the  exercise  event  and  its  perfor- 
mance during  the  course  of  the  exercise.  This  object  is 
identified  by  the  target  designation,  which  is  a  serial 
number  for  a  range  target,  or  a  ship  designation  or  hull 
number  if  the  target  was  an  actual  submarine  or  ship.  If  a 
ship  or  submarine  is  used  as  a  target  then  the  only  target 
information  that  applies  are  track  quality  and  sound  augmen- 
tation information.  The  TARGET  RESULTS  object  records  the 
success  or  failure  of  target  recovery  operations,  and  also 
contains  the  LOST  object,  which  stores  data  about  lost 
torpedoes  and  targets. 

The  LOST  Object,  contained  within  the  TARGET 
RESULTS  and  WEAPON  RESULTS  objects,  records  information 
pertaining  to  lost  torpedoes  and/or  targets.  It  is  consi- 
dered separate  from  the  WEAPON  RESULTS  and  TARGET  RESULTS 
objects  because  its  occurrence  is  so  rare  (perhaps  three  or 
four  times  a  year).  Each  instance  is  identified  by  the 
weapon  type  (mk)  and  serial  number,  or  target  designation 
and   serial  number.   The   LOST  object   is  associated   with  a 
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particular   event,   thus  other   needed  information   for  that 
object  can  be  obtained  from  other  objects  of  that  event. 
2.    Functional  Requirements 

The  objects  described  above  reflect  the  users' 
view  of  what  must  be  captured  in  the  new  system.  The  func- 
tional requirements  specify  the  actual  database  application 
requirements  of  the  system,  and  are  portrayed  graphically  in 
the  data  flow  diagrams  (DFD)  in  Appendix  D. 

a.    Schedule    Appl ication 

The  functional  requirements  of  the  schedule 
application  consist  of  creating  an  exercise  event  and  dele- 
ting/modifying an  exercise  event.  The  term  "exercise  event" 
as  used  here  means  both  the  Exercise  object  and  its  associa- 
ted objects  (Brief,  User,  Weapon  and  Target).  The  creation 
and  modification/deletion  of  an  exercise  are  shown  DFD  (A) 
and  (B),  respectively.  In  creating  a  new  event,  the  schedu- 
ler gathers  data  (objects)  from  the  Program  Manager,  the 
Program  Engineer,  NUWES  and  the  Supporting  Commands.  This 
information,  combined  with  the  monthly  planning  schedule 
stored  in  the  O-Base  database,  is  used  to  create  a  single, 
unique  exercise  event  (object).  The  scheduler  forwards 
exercise  events  for  an  entire  week,  in  the  form  of  a  tenta- 
tive weekly  schedule,  to  the  Range  Manager  for  review  and 
approval.  Any  modifications  to  an  event  by  the  Range  Manager 
are  sent  back  to  the  scheduler  for  change  and  are  re-sub- 
mitted for  approval.  The  approved  weekly  schedule  is 
returned  to  the  scheduler  who  distributes  it  and  issues  a 
Weekly  Briefings  Report,  depicting  all  scheduled  briefs  for 
the  week,  including  times,  locations  and  briefing  officers. 

In  the  second  part  of  the  schedule  applica- 
tion, the  scheduler  receives  recommended  changes  to  and 
deletions  from  events  in  the  weekly  schedule.  These 
recommendations  come  from  the  Program  Manager,  the  Program 
Engineer,  the  client  User  Commands,  NUWES  and  the  Supporting 
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Commands  and  are  forwarded  to  the  Range  Manager  for  appro- 
val. Upon  receipt  of  approval,  the  scheduler  issues  an 
updated  weekly  schedule  and  a  modified  Weekly  Briefings 
report  reflecting  the  changes. 

b.  Exercise    Results    Appl ication 

The  third  DFD  portrays  the  functional  re- 
quirements of  the  Exercise  Results  application,  which  con- 
sist of  those  processes  necessary  to  gather  and  store  exer- 
cise results  data.  This  includes  not  only  the  Result  object, 
but  also  the  Platform,  Attack,  Weapon  Result,  Target  Result 
and  Lost  objects.  These  data  can  then  be  used  for  user 
performance  evaluations  and  for  the  creation  of  periodic  and 
aperiodic  reports.  Data  contained  in  the  Exercise  event  and 
stored  in  the  O-Base  database  are  retrieved  by  a  clerk  and 
combined  with  post-exercise  data  from  the  O-Base  database 
(Results  Object)  to  create  an  Exercise  Summary,  which  is 
passed  to  the  Program  Engineer  ( PE )  for  review  and  approval. 
Also  passed  to  the  PE  is  a  list  of  scheduled  exercise  events 
in  the  database  which  have  no  corresponding  Results  object. 
The  PE  files  the  Summary  and  takes  action  to  ensure  that  all 
exercise  events  have  associated  Results  in  the  O-Base  data- 
base. The  PE  also  retrieves  P 1  a t f orm/ At tac k  data  from  the 
database  in  order  to  produce  a  Mk-46  Rapid  Feedback  Firing 
Report  for  distribution  to  the  user  command  following  the 
exercise.  The  Operations  Analyst  and  Program  Manager 
retrieve  Results  and  Platform  data  from  the  database  in 
order  to  create  periodic  reports  for  the  Fleet  Commanders, 
User  Commands  and  for  internal  FACSFAC  distribution.  Lastly, 
the  communicator,  who  may  also  be  the  PE ,  creates  and 
distributes  the  Mk-46  Quarterly  Firing  Report  to  Naval  Sea 
Systems  Command. 

The  Update,  Display  and  Control  Mechanisms 
required  for  the  system  are    as  shown  in  Appendix  E. 
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Ill .  SYSTEM  DESIGN 

The  third  phase  of  the  systems  analysis  process  is  the 
design  of  the  system.  It  is  during  this  phase  that  the 
foundation  of  the  database  structure  is  built.  The  design 
step  actually  consists  of  two  phases:  the  logical  design 
phase  and  the  application  design  phase.  The  goal  of  logical 
database  design  is  to 

represent  objects  in  the  database  using  relations  that 
(i)  provide  the  data  needed  to  construct  user  objects 
and  (2)  a.re  robust  enough  to  allow  rows  to  be  inserted, 
deleted  and  modified  without  resulting  in  inconsisten- 
cies or  errors  in  the  stored  data.   [Ref .  3 : pg .  133] 

Under  logical  database  design,  items  to  be  discussed 
include  the  concepts  of  relations,  primary  and  foreign  keys, 
relationships,  relationship  constraints  and  normalization. 
In  the  application  design  phase,  the  applications  and  their 
scope  will  be  addressed,  along  with  control  mechanisms  and  a 
description  of  the  menu  hierarchy. 

A.    LOGICAL  DATABASE  DESIGN 

In  this  step,  each  object  developed  in  the  user's 
requirements  phase  is  translated  into  one  or  more  two-dimen- 
sional tables,  called  relations.  Each  row  in  a  relation  is 
called  a  tuple,  and  corresponds  to  a  record.  Each  column  is 
an  attribute,  and  corresponds  to  a  field.  The  relations 
thus  created  are  depicted  in  Appendix  F.  A  simple  object, 
such  as  Brief  or  Target,  which  contains  only  single-valued, 
non-object  properties,  is  represented  by  a  single  relation. 
A  composite  object,  on  the  other  hand,  is  one  containing  one 
or  more  non-object  multivalued  properties,  and  requires  more 
than  one  relation  for  their  representation.  For  example,  the 
Result  object  (Appendix  A)  contains  several  non-object, 
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multivalued  properties  which  are  translated  into  the  Support 
and  Cancel  relations  given  in  Appendix  F.  A  compound  object 
contains  at  least  one  object  property,  requiring  translation 
of  that  object  into  several  relations,  each  of  which  could 
stand  on  its  own.  For  example,  the  Exercise  object  of  Appen- 
dix A  contains  the  object  properties  Brief,  User  and  Target, 
each  of  which  forming  its  own  relation  in  Appendix  F. 

1.  Relation  Keys 

Each  relation  has  a  set  of  attributes,  called  the 
key,  which  uniquely  identifies  a  tuple.  These  keys  are 
underlined.  In  the  Exercise  relation  the  key  consists  of 
Exercise  Type  ( Exer )  and  Event  Number  ( Event ) .  In  all  of  the 
other  relations  of  the  Schedule  Application,  except  for 
Brief,  Exercise  Type  and  Event  Number  appear  as  part  of  the 
key,  where  they  represent  a  foreign  key  (the  key  of  another 
relation),  as  indicated  by  the  asterisk.  In  the  Brief  rela- 
tion, Brief  Title  (Title)  and  Brief  Time  ( Time )  are  the  key 
attributes,  but  the  relation  contains  Exer  and  Event  as  a 
foreign  key . 

In  the  Exercise  Results  Application,  Exer  and 
Even  t  are  also  common  in  most  of  the  keys,  the  exceptions 
being  the  Attack  relation  and  those  multi-valued  objects  and 
attributes  associated  with  it.  Exer  and  Event  are,  however, 
present  in  the  Attack  relation  as  a  foreign  key,  as  are 
Command  and  Sideno  (comprising  the  Platform  key).  Thus,  an 
attack  can  be  associated  with  both  an  exercise  event  and  a 
specific  platform.  In  a  similar  manner,  the  Lost  relation, 
with  its  multiplicity  of  foreign  keys,  can  be  associated 
directly  with  an  exercise,  an  attack,  a  weapon  and/or  a 
target . 

2.  Relationships 

A  binary  relationship  is  one  that  involves  only 
two  record  types.  Whereas  an  object  was  converted  on  a  one- 
to-one    basis    into    a    relation    (record    type),   the 
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relationships  between  those  record  types  a,re  not  necessarily 
limited  to  one-to-one.  In  fact,  in  this  database  the  majori- 
ty of  the  relationships  are  one-to-many.  Referring  again  to 
the  relation  diagrams  of  Appendix  F,  a  given  exercise  may 
have  multiple  users  associated  with  it,  as  indicated  by  the 
"fork"  on  the  User  end  of  the  connecting  line.  Similarly,  an 
exercise  can  have  many  briefs  and  targets  and  a  user  may 
have  more  than  one  weapon. 

One-to-one  relationships  exist  between  the  Attack 
and  WeaponR  record  types,  in  that  any  attack  can  only  have  a 
single  weapon  result  associated  with  it.  Correspondingly,  a 
weapon  can  only  have  one  attack  associated  with  it  during  a 
given  exercise.  The  Lost  relation  similarly  shares  one-to- 
one  relationships  with  WeaponR  and  TargetR  record  types. 

A  simplified  relationship  diagram  for  the  schedule 
application  can  be  seen  in  Figure  3.1  below,  and  one  for  the 
exercise  results  application  in  Figure  3.2. 
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Figure  3.1   Schedule  Application  Relationships 
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Figure  3.2   Results  Application  Relationships 

3.    Relationship  Constraints 

Another  notation  used  in  Figures  3.1  and  3.2  and 
in  Appendix  F  is  one  to  indicate  a  mandatory  or  optional 
relationship  between  two  record  types.  A  circle  at  the  end 
of  a  line  indicates  an  optional  association.  For  example,  an 
exercise  may  have  a  target  (or  more  than  one)  associated 
with  it,  and  a  platform  may  conduct  one  or  more  attack.  A 
bar  at  the  end  of  the  connector  indicates  a  mandatory  rela- 
tionship. For  example,  a  weapon  results  relation  (WEAPONR) 
must  have  an  attack  associated  with  it. 


20 


The  exercise  and  brief  relationships  are  optional 
in  each  direction.  This  is  because  an  exercise  may  have  only 
one  brief  associated  with  it  (rather  than  the  normal  two), 
or,  in  the  case  of  a  range  maintenance  period  (designated  as 
an  exercise  for  scheduling  purposes),  there  may  be  no  sched- 
uled brief  at  all.  Additionally,  a  brief  may  be  scheduled 
that  does  not  relate  to  a  specific  exercise. 
4.    Normalization 

The  relations  created  in  this  project  are  all  in 
at  least  third  normal  form  ( 3NF ) .  A  relation  can  be  con- 
sidered as  being  in  3NF  if  (1)  all  non-key  attributes  are 
dependent  on  all  of  the  key,  and  (2)  if  it  contains  no 
transitive  dependencies.  For  example,  in  the  case  of  the 
Target  relation,  the  Geometry,  Acoustics,  Tpinger  and 
Lnchveh  attributes  are  each  dependent  on  Exer ,  Even  t  and 
Tq tdesiq  and  only  on  those  attributes. 

B.    APPLICATION  DESIGN 

Data  flow  diagrams  (DFD)  were  developed  during  the  user 
requirements  phase  in  order  to  identify  the  functional  needs 
of  the  organization.  In  the  application  design  step,  these 
DFDs  are  transposed  into  a  functional  hierarchy  structure, 
as  shown  in  Appendix  G.  Each  block  or  module  h,3  =  3  ^P^F  +  f+P 
object  or  function,  and  each  module  contains  sub-modules, 
selection  of  which  will  result  in  a  specific  task  being  per- 
formed. These  hierarchy  structures  also  serve  to  delineate 
the  applications  and  the  scope  of  the  project,  which  have 
been  well-defined  in  previous  chapters  and  will  not  be 
repeated  here. 
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1.  Control  Mechanisms 

After  determining  the  number  and  scope  of  the 
applications,  the  next  step  in  application  design  is  to 
devise  the  control  mechanisms  associated  with  the  applica- 
tions. A  menu-driven  application  is  considered  to  be  the 
most  appropriate  control  mechanism  for  this  project,  due 
primarily  to  its  simplicity  of  design  and  ease  of  use. 
Minimum  time  will  be  necessary  to  train  the  operators  in  the 
use  of  the  menus,  because  they  are  self-explanatory.  Addi- 
tionally, a  menu  driven  application  is  far  easier  to  under- 
stand than  one  which  is  command-driven. 

2.  Menu  Hierarchy  Descriptions 

The  final  stage  of  application  design  consists  of 
converting  the  entity-relationship  structures  into  a  series 
of  menus.  A  set  of  menus  is  perhaps  the  easiest  method  of 
providing  user  interface  with  the  application  functions. 
Additionally,  they  simplify  user  learning,  understanding  and 
utilization  of  the  system.  Examples  of  the  various  menus 
corresponding  to  the  hierarchic  structures  are  illustrated 
in  the  figures  and  described  below. 

a  .    Ma  i  n    Men  u 

The  main  O-Base  menu  shown  in  Figure  3.3 
allows  the  user  to  select  which  application  to  enter,  or 
permits  him  to  exit  back  to  the  operating  system.  As  men- 
tioned above,  permission  to  enter  a  selected  function  will 
be  governed  by  the  password  of  the  user. 
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Schedule  Application    1 


Results  Application 


Exit  to  System    3 


Enter  Desired  Selection:  __. 


Figure  3.3   System  Main  Menu 

b.  Schedu 1 e    fippl ication    Menu 

The  Schedule  Application  menu  (Figure  3.4) 
provides  the  user  with  the  options  of  selecting  an  item 
within  the  schedule  application  for  update,  or  performing 
one  of  the  two  print  functions  associated  with  the  applica- 
tion. The  user  also  has  the  option  to  exit  to  the  main  menu. 
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SCHEDULE    APPLICATION    MENU 

Event      1 

Brief     2 

User     3 

Weapon    4 

Target    6 

Print  Schedule   .  .    6 
Print  Brief  Rpt    .  .    7 

EXIT  TO  MAIN  MENU    .    8 

Enter  Desired  Selection: 

Figure  3.4   Schedule  Application  Menu 


b.  Sc hedu 1 e    Func tions    Menu 

Following  selection  of  an  object  to  update 
from  the  previous  menu,  the  user  is  presented  with  a  menu 
displaying  the  various  functions  available  (Figure  3.5). 
When  creating  (adding)  an  event,  the  user  enters  all  known 
data  associated  with  that  event,  including  brief,  user, 
weapon  and  target  information.  Additionally,  a  brief  can  be 
added,  modified  or  deleted  individually.  Modification  of 
user,  weapon  and  target  data  associated  with  an  existing 
exercise  event  is  accomplished  through  modifying  the  event 
itself.  Deletion  of  an  event  deletes  all  user,  weapon, 
target  and  brief  information  associated  with  that  event. 
The  user  also  has  the  option  to  execute  user — defined  queries 
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on  each  of  the  exercise  objects.  Lastly,  the  user  can  either 
exit  to  the  previous  menu  or  exit  to  the  main  menu. 


SCHEDULE  FUNCTION  MENU 


Add    1 

Modify 2 

Delete 3 

Query    4 

EXIT  TO  SCHED  MENU    .  .    5 
EXIT  TO  MAIN  MENU     ...    6 

Enter  Desired  Selection  :    __ 


Figure  3.5   Schedule  Functions  Menu 

c.    Exercise    Results    Application    Menu 

This  menu  (Figure  3 . 6 )  permits  the  user  to 
enter  into  the  second  application  of  the  system  —  the 
Exercise  Results  application.  When  a  selection  is  made  of 
one  of  the  objects  associated  with  the  results  application, 
the  user  is  presented  with  a  Results  Functions  menu  similar 
to  the  one  for  the  Schedule  application  (see  Figure  3.5).  It 
is  through  the  functions  menu  that  the  update  of  the  selec- 
ted object  is  performed.  Additionally,  the  user  has  the 
option   of  selecting  a   Report  Generator  function   from  this 
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menu.   Although  beyond   the  scope   of   this  project,  future 

enhancements   to  the  system  could  permit   automated  reports 

through  this   function.  The  user  also   may  exit  back  to  the 
main  menu . 


RESULTS    APPLICATION    MENU 


Exercise  Result   , .  ,  .  1 

Platform     2 

Attack    3 

Weapon    4 

Target     5 

Report  Generator    .  .  6 

EXIT  TO  MAIN  MENU    ...  7 


Enter  Desired  Selection. 


Figure  3.6   Results  Application  Menu 

If  the  user  desires  to  create  a  new  exercise 
result,  he  selects  "Exercise  Result"  from  the  Results  Ap- 
plication Menu,  followed  by  "Add"  from  the  Results  Functions 
Menu.  He  is  then  cycled  through  all  relevant  objects  as- 
sociated with  the  new  exercise  result.  Individual  objects, 
such  as  Attack,  atb  added  in  the  same  manner.  Deletion  of  a 
Platform  requires  prior  deletion  of  any  Attack  and  Weapon 
associated  with  that  platform.  Deletion  of  a  Result  will 
cause  the  deletion  of  all  objects  associated  with  it.  Any 
other  object  may  be  deleted  individually. 
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IV.  SYSTEM  IMPLEMENTATION 

A.     INTRODUCTION 

The  second  step  in  the  design  phase,  and  the  final  step 
in  the  systems  analysis  cycle,  is  implementation.  The  main 
task  of  of  implementation  is  to  construct  a  system  according 
to  the  design.  In  this  step,  the  relations,  rows  and  at- 
tributes of  the  design  phase  are  translated  into  DBMS-speci- 
fic tables,  records  and  fields. 

Based  on  application  design,  the  application  develop- 
ment tools  of  Oracle  are  used  to  construct  the  forms,  re- 
ports and  menus  needed  in  the  system.  The  Oracle  DBMS  will 
be  addressed  after  a  discussion  of  table  and  screen 
genera t  ion . 

1.    Database  Tables 

Data  requirements  were  identified  during  the  user 
requirement  phase  and  were  presented  in  the  form  of  objects. 
During  the  logical  design  phase  of  the  last  chapter,  the 
objects  were  translated  into  corresponding  relations,  and 
relationships  between  the  relations  were  established.  In  the 
implementation  phase,  these  relations  are  translated  into 
DBMS-specific  (Oracle)  tables.  These  tables  are  the  essence 
of  data  storage  and  management  in  the  database  management 
system.  Each  table  consists  of  a  series  of  columns,  or 
fields,  which  equate  to  the  attributes  of  the  logical  rela- 
tions. A  single  row  of  data  within  a  table  is  referred  to  as 
a  record . 

A  listing  of  all  tables  created  for  this  project 
is  found  in  Appendix  H.  The  first  section  of  the  appendix 
contains  those  tables  necessary  for  the  storage  and  display 
of  the  actual  data,  while  the  second  section  contains  the 
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look-up  tables  designed  to  assist  the  user  in   making  proper 
entries  in  various  fields. 

Appendix  I  presents  the  associations  between  the 
descriptive  names,  domain  names  and  actual  table  field  names 
for  each  object. 

2.    Screen  Designs 

The  second  task  of  the  user  requirements  phase  was 
the  identification  of  the  functional  requirements  of  the 
system.  The  task  was  accomplished  by  the  creation  of  a 
series  of  data  flow  diagrams  ( DFD ) .  The  logical  design  phase 
converted  the  DFDs  into  menus  that  allowed  the  user  to 
control  the  insertion,  modification  and  deletion  functions. 
During  the  implementation  phase,  the  menus  are  translated 
into  screens,  or  views,  which  provide  the  user  the  actual 
mechanisms  for  update  and  display  of  the  data.  The  screens 
are  the  materializations  of  the  objects,  containing  selected 
rows  and  columns  of  the  underlying  tables.  In  some  cases,  a 
single  screen  consists  of  two  or  more  joined  tables.  Because 
these  screens  are  not  stored  as  actual  physical  tables,  the 
views  can  be  termed  virtual  tables.  Appendix  J  contains  the 
various  screens  developed  for  the  two  applications.  The 
following  section  describes  the  DBMS  used  for  implementation 
of  this  project. 

B.    ORACLE  RELATIONAL  DATABASE  MANAGEMENT  SYSTEM  (RDBMS) 

Oracle  is  an  extremely  powerful,  Standard  Query  Lang- 
uage (SQL)-based  relational  database  management  system.  The 
Oracle  corporation  has  added  non-standard  extensions  to  the 
SQL  language,  thus  term  their  product  "SQL#Plus".  Due  to  its 
utility  at  both  the  stand-alone  microcomputer  level  and  the 
network  level,  and  its  high  degree  of  portability,  it  was 
selected  by  FACSFAC  as  the  program  of  choice  for  their 
automated  database  system.  Hardware  and  system  requirements 
of  Oracle  were  presented  in  Chapter  I. 
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The  Oracle  products   include  a  variety  of   applications 
development  and  generation  tools,  providing 


complete  facilities  that  systems  designers  and  devel- 
opers can  use  to  design,  develop  and  test  software 
products  whose  engine  is  the  Oracle  RDBMS.  [Ref.  5 : pg . 
x  x  v  ] 


The   most   significant  tools   used   in  this   project  include 
SQL*Plus,  SQL*Forms  and,  to  some  extent,  SQL*Report. 

1.  SQL*Plus 

The  developer  uses  the  SQL*Plus  query  language  to 
"create,  store,  modify,  retrieve,  print  and  manage  informa- 
tion in  an  ORACLE  database"  [Ref.  6 : pg .  i].  Of  all  the  pro- 
grams in  the  Oracle  system,  it  provides  the  most  direct 
access  to  the  data.  It  is  through  this  tool  that  the  tables 
were  created  and  the  data  was  inserted  into  the  tables. 

2.  SQLtForms 

This  tool  is  used  by  both  the  system  developer  and 
the  system  operator.  The  developer  selects  the  rows  and 
columns  of  the  tables  for  display  in  screens  through  the  use 
of  the  SQL*Forms  program.  This  portion  of  the  program  is 
called  Design  forms.  After  the  form  has  been  generated,  the 
Run  form  procedure  permits  the  operator  to  work  with  the 
information  that  the  form  accesses.  Once  the  form  is  dis- 
played, the  operator  is  able  to  perform  the  logical  menu 
functions  of  insertion,  deletion  and  modification  described 
in  the  previous  chapter. 

3.  SQL*Report 

Like  SQL*Forms,  this  program  also  has  two  utili- 
ties. The  Report  Text  Formatter  ( RPF )  is  "a  genera  1 -purpose 
text  formatter  for  a  variety  of  word  processing  applications 
...."  [Ref.  7 : pg .  9].  The  second  utility  is  the  Report 
Generator  (RPT),  which  enables  the  developer  to  extract 
specific  data   from  the  database  and  include  it  in  a  report. 
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RPT  must   be   used  in   conjunction  with   some   type  of   text 
■formatter,  such  as  RPF  . 

A  far  more  powerful  report  generator,  SQL*Report- 
writer,  has  recently  been  marketed  by  the  Oracle  corpora- 
tion, but  was  unavailable  for  this  project. 

C.  SOFTWARE  DOCUMENTATION 

1.  User  Manual 

The  user  manual  written  for  this  system  is  provi- 
ded in  Appendix  K.  It  is  designed  for  a  user  familiar  with 
the  Oracle  RDBMS ,  having  had,  as  a  minimum,  attended  an 
operator  training  course  or  read  an  operator  tutorial. 
Because  implementation  of  the  system  does  not  lend  itself  to 
a  menu  layout  in  the  Oracle  environment,  the  logical  menu 
functions  described  in  the  previous  chapter  are  performed 
through  the  activation  of  various  keyboard  keys.  The  func- 
tion keys  and  spec i a  1 -pur pose  keys  used  by  Oracle  and/or 
custom-designed  for  this  system  are  defined  in  the  user 
manual .  Also  included  in  the  manual  are  the  various  field 
constraints,  formats  and  masks  which  must  be  adhered  to 
while  creating  new  records. 

2.  Main  Program 

The  program  developed  for  this  project  is  written 
in  SQL,  a  powerful  fourth  generation  language  ( 4GL ) .  Because 
it  is  a  4GL ,  standard  program  descriptions  (structure 
charts,  etc.)  and  subroutines  are  not  applicable  to  the 
actual  design.  The  length  of  the  program  precludes  its 
incorporation  as  an  appendix. 

D .  REPORTS 

The  operator  has  the  option  to  print  two  standard, 
automated  reports  through  the  system:  1)  a  weekly  schedule 
of  activities,  and  2)  a  weekly  briefings  report.  These 
reports  were  created  using  SQL*Report.  An  example  of  each  is 
presented  in  Appendix  L. 
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V.    CONCLUSIONS  AND  RECOMMENDATIONS 

A.    SUMMARY  AND  CONCLUSIONS 

The  amount  and  complexity  of  the  operational  data 
collected  and  stored  by  the  Fleet  Area  Control  and  Surveil- 
lance Facility  will  soon  overwhelm  the  manual  data  handling 
capabilities  of  the  command.  This  study  develops  a  relation- 
al database  system  prototype  to  assist  the  organization  in 
those  critical  areas  of  its  activities.  One  of  the  main 
goals  is  to  increase  the  speed  and  accuracy  of  data  input, 
thereby  enhancing  the  effectiveness  and  productivity  of  the 
unit.  Additionally,  a  powerful  database  guery  function  and  a 
report  generation  capability  will  greatly  facilitate  user 
performance . 

The  system  is  viewed  as  being  two  separate  but  interac- 
tive applications.  The  scheduling  application  is  used  to 
input,  modify  and  delete  data  elements  associated  with 
creation  of  a  weekly  schedule  of  activities  and  a  weekly 
briefings  report.  The  results  application  is  designed  to 
allow  for  the  input,  modification  and  deletion  of  operation- 
al data  gathered  during  the  execution  of  various  scheduled 
exerc  ises . 

The  power  and  flexibility  of  ORACLE  made  it  the  program 
of  choice  by  FACSFAC  for  their  database  system.  Despite  its 
advantages,  ORACLE  is  difficult  to  apply  for  the  novice 
user,  thus  a  detailed  Users  Manual  is  provided  in  Appendix  K 
to  assist  the  operator.  The  prototype  system  was  designed 
with  the  goal  of  making  it  as  easy  as  possible  to  understand 
and  use,  however  a  certain  level  of  operator  knowledge  of 
ORACLE  is  assumed.  The  Users  Manual  contains  a  section 
describing  the  various  function  keys  and  their  applications 


31 


in  ORACLE,   as  well  as  the   special  purpose  keys   custom  de- 
signed into  the  prototype  model  to  make  it  user-friendly. 

B.    RECOMMENDATIONS  AND  FUTURE  WORK 

Establishment  of  a  relational  database  allows  for 
future  expansion  and  capability  enhancements.  Using  data 
gathered  and  stored  in  the  results  application,  SQL#Report- 
writer  can  be  used  to  develop  an  automated  report  generation 
capability  for  the  operations  analyst.  Additionally,  the 
system  can  be  enhanced  through  the  incorporation  of  an 
automatic  scheduling  and  conflict  resolution  decision  sup- 
port program.  Development  of  these  two  augmentations  to  the 
prototype  will  serve  to  increase  command  efficiency  even 
further.  Finally,  the  ability  of  ORACLE  to  be  utilized  in  a 
network  environment  conforms  well  with  the  strategic  infor- 
mation technology  goals  of  the  organization.  Development  of 
an  interactive  network  linking  the  three  databases  is  open 
for  further  study. 
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APPENDIX  A 


RELATIONAL  DATABASE  OBJECTS 


EXERCISE  OBJECT 

Exercise  Type 

Event  Number 

Exercise  Description 

Scheduled  Start  Time 

Scheduled  Stop  Time 

MOCS  Start  Time 

MOCS  Stop  Time 

Operational  Area 

Exc lusi ve 

Primary  Tgt  Recovery 

Secondary  Tgt  Recovery 

Primary  Wpn  Recovery 

Secondary  Wpn  Recovery 

Weapon  Haulback 

Tracking  Type 

Project  Engineer 

Operation  Controller 

Operation  Analyst 

Safety  Officer 

Green  Message  Required 

Green  Message  Sent 

Submarine  Relaxation 

Message  Required 

Air  Space  Allocated 

Communications 

Commen  ts 

BRIEF    MV 

USERS    MV 

TARGET   MV 

RESULTS 

BRIEF  OBJECT 


Brief  Title 
Date  and  Time 
Location 
Briefer 


TARGET  OBJECT 


*  Exercise  Type 

*  Event  Number 
Target  Designation 
Target  Geometry 
Acoustics  Code 
Pinger  Channel 
Launch  Vehicle 


WEAPON  OBJECT 

* 

Weapon  Type 
Command  Name 

Number  Scheduled 
Pinger  Channel 

USERS  OBJECT 


*  Exercise  Type 

*  Event  Number 
Command  Name 
Number  of  Units 
EATS  Transponder 
Pinger  Channel 
WEAPON   MV 
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RESULTS  OBJECT 

Exercise  Type 

Event  Number 

Exercise  Description 

Exercise  Attainmen 

t 

Comex 

Finex 

Scheduled  Start  Time 

Scheduled  Stop  Time 

Oparea 

Visibi 1 i ty 

Sea  State 

Reason  Canceled 

MV 

Hours  Lost 

MV 

Cancel  Start  Time 

MV 

Support  Platform 

MV 

Support  Sidenumber 

MV 

Support  Used 

MV 

Classified  Comment 

s 

Unclassified  Comments 

PLATFORM 

MV 

TARGET  RESULTS 

MV 

LOST 

OBJECT 

Mk_ 

Mod 

Seria 

1  Number 

*   Time 

Lost 

Latit 

ude 

Long  i 

tude 

Implosion 

Water 

Depth 

TARGET  RESULTS  OBJECT 

* 
* 

Exercise  Type 

Event  Number 

Target  Designation 

Mk 

Serial  Number 

Mod 

Geometry 

Target  Performance 

Launch  Time 

Target  Recovered 

Recovery  Vehicle 

Sound  Level 

Frequency 

Track  Quality 

LOST                 MV 

WEAPON  RESULTS  OBJECT 

* 

TOF 

* 

Mk 

Mod 

Serial  Number 

Torpedo  Performance 

Search  Time 

Weapon  Recovered 

Recovery  Vehicle 

Recovery  Time 

Bring  Back  Vehicle 

Track  Quality 

LOST                 MV 
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! 

ATTACK 

OBJECT 

Time  of 

Fire 

#   Command 

Name 

*   Side  Number 

Start  0 

P 

Actual 

Target 

Course 

Actual 

Target 

Bearing 

Actual 

Target 

Speed 

Actual 

Target 

Range 

Actual 

Target 

Depth 

Target 

Maneuver  Time 

Target 

Maneuver 

Course 

Target 

Maneuver  Speed 

Target  Doppler 

Solution  Bearing 

Solution  Course 

Solution  Speed 

Solution  Range 

Heading  at  TOF 

Speed  at  TOF 

Mode 

Sonar  Setting 

Contact  Type 

Acquired 

Eval  of  Attack 

Search  Depth 

Commen  ts 

Altitude 

Delivery  Method 

Ph 

Bearing  to  Splash 
Point 

Range  to  Splash 
Point 

Acquired 

Eval  of  Attack 

Search  Depth 

Commen  ts 

WEAPON  RESULTS 


PLATFORM  OBJECT 

* 

Exercise  Type 

* 

Event  Number 

Command  Name 

Side  Number 

Showed  Up 

Track  Quality 

Lof  ar 

Dif  ar 

Dicas 

Vlad 

Weapon  Assigned 
Number  of  Weapons 
No  Drop 

ATTACK 


MY 
MV 
MV 

MV 
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APPENDIX  B 


OBJECT  DEFINITIONS 


EXERCISE  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 
Event  Number 
Exercise  Description 
Schedule  Start  Time 
Schedule  Stop  Time 
MOCS  Start  Time 
MOCS  Stop  Time 
Operational  Area 
Exclusive  Use 
Primary  Target 

Recovery  Vehicle 
Secondary  Target 

Recovery  Vehicle 
Primary  Weapon 

Recovery  Vehicle 
Secondary  Weapon 

Recovery  Vehicle 
Weapon  Haulback 

Vehic le 
Tracking  Type 
Project  Engineer 
Operation  Controller 
Operation  Analyst 
Safety  Officer 
Green  Required 
Green  Sent 
Submarine  Relaxation 

Message 
Air  Space 
Communications 
Commen  ts 


BRIEF: 
USERS: 
TARGET: 
RESULTS: 


BRIEF  object; 
USER  object; 
TARGET  object 
RESULTS  objec 


Exer 

Event 

Exdesc 

Time-Schstart 

Time-Schstop 

Time-MOCS  Start 

Time-MOCS  Stop 

Oparea 

Exc lusi ve 

Recovery-Pri 

Recovery -Sec 

Recovery-Pri 

Recovery- Sec 

Recovery-Hau 1 bac  k 
Tracking  Type 
Personne 1 -Pe 
Personne 1 -Oc 
Personnel -Oa 
Personne 1 -So 
Message-Req 
Message-Sent 

Message-Sub 

Air  Space 

Communications 

Commen  ts 
MV 
MV 

;   MV 
t 
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BRIEF  OBJECT 

Descriptive  Name Domain  Name 


Brief  Title 
Brief  Time 
Location 
Briefer 


Brief  Title 
Time-Brief 
Location 
Personnel-Brief 


USERS  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 

Event  Number 

Command  Name 

Number  of  Units 

EATS  Transponder 

Pinger  Channel 

WEAPON:   WEAPON  object 


Exer 
Event 
Command 
Number-U 
Transponder 
Pinger-U 
MV 


TARGET  OBJECT 


Descriptive  Name 


Exercise  Type 

Event  Number 

Target  Designation 

Geometry 

Acoustics 

Pinger 

Launch  Vehicle 


Domain  Name 


Exer 

Even  t 

Target  Designation 

Geometry  Code 

Acoustics 

Pinger-T 

Launch 


WEAPON  OBJECT 


Descriptive  Name 


Domain  Name 


Mk 

Command  Name 

Number  Scheduled 

Pinger 


Mk 

Command 
Number-S 
Pinger-W 
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RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 

Event  Number 

Exercise  Description 

Comex 

Finex 

Scheduled  Start  Time 

Scheduled  Stop  Time 

Operational  Area 

Visibi 1 i ty 

Sea  State 

Reason  Canceled    MV 

Hours  Lost  MV 

Cancel  Start  Time  MV 

Support  Platform   MV 

Support  Side  No.   MV 

Support  Used       MV 

Classified  Comments 

Unclassified  Comments 


Exer 

Event 

Exdesc 

Time-C 

Time-F 

Time-Schstart 

Time-Schstop 

Oparea 

Visible 

Seastate 

Canceled 

Hours 

Time-Cancel 

Command 

Sidenumber 

Used 

Comments 

Commen  t.s 


PLATFORM;  PLATFORM  object;  MV 

TARGET  RESULTS;  TARGET  RESULTS  object;  MV 

PLATFORM  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 

Event  Number 

Command  Name 

Side  Sumber 

Showed  Up 

Trac  k  Qua  1 i  ty 

Lof  ar 

Dif  ar 

Dicass 

Vlad 

Weapon  Assigned     MV 

Number  of  Weapons 

Scheduled       MV 
No  Drop  MV 

ATTACK;  ATTACK  object; 


Exer 

Event 

Command 

Sidenumber 

Showed 

Trac  k  Qual i ty 

Sonobuoy  no. 

Sonobuoy  no. 

Sonobuoy  no. 

Sonobuoy  no. 

Mk 

Number-S 
Nodrop 


MV 
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TARGET  RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Exercise  Type 

Event  Number 

Target  Designation 

Mod 

Serial  Number 

Target  Performance 

Geometry 

Launch  Time 

Target  Recovered 

Recovery  Vehicle 

Sound  Level 

Frequency 

Track  Quality 

LOST;  LOST  object 


Exer 

Event 

Target  Designation 

Mod 

Serial  Number 

Target  Performance 

Geometry  Code 

Time-L 

Recovered 

Recovery 

Sound 

Frequency 

Track  Quality 


WEAPON  RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Time  of  Fire 
Mk 
Mod 

Serial  Number 
Torpedo  Performance 
Search  Time 
Weapon  Recovered 
Recovery  Vehicle 
Recovery  Time 
Bring  Back  Vehicle 
Track  Quality 
LOST;  LOST  object 


TOF 

Mk 

Mod 

Serial  Number 

Torpperf 

Search-seconds 

Recovered 

Recovery 

Minutes -Recover 

Recovery 

Track  Quality 


LOST  OBJECT 


Descriptive  Name 


Domain  Name 


Mk 

Mod 

Serial  Number 

Time  Lost 

Latitude 

Longi  tude 

Implosion 

Water  Depth 


Mk 

Mod 

Serial  Number 

Time-Lost 

Lat 

Long 

Depth-Imp 

Depth-Water 
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ATTACK  OBJECT 

Descriptive  Name Domain  Name 

Time  of  Fire  Time-Tof 

Command  Name  Command 

Start  Op  Time-Start-time 

Actual  Target  Course  Compass-Tc 

Actual  Target  Bearing  Compass-Tb 

Actual  Target  Speed  Kts-Ts 

Actual  Target  Range  Range-T 

Actual  Target  Depth  Depth-T 

Target  Maneuver  Time  Minutes-Maneuver 

Target  Maneuver 

Course  Compass-Tm 
Target  Maneuver 

Speed  Kts-Tm 

Target  Doppler  Doppler 

Solution  Bearing  Compass-Sb 

Solution  Course  Compass-Sc 

Solution  Speed  Kts-S 

Solution  Range  Range-S 

Heading  at  TOF  Compass-Heading 

Speed  at  TOF  Speed 

Altitude  Height 

Mode  Modecode 

Sonar  Setting  Sonar 

Contact  Type  Contact  Code 

Delivery  Method  Delivery  Code 
Bearing  to  Splash 

Point  Compass-Sp 1 ashp t 
Range  to  Splash 

Point  Range-Spl ashpt 

Acquired  Acquired 

Eval  of  Attack  Eval 

Search  Depth  Depth-S 

Comments  MV  Comments 

Line  Number       MV  Linenumber 
WEAPON  RESULTS;  WEAPON  RESULTS  object; 
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APPENDIX  C 


DOMAIN  DEFINITIONS 


Acoustics  Code: 
char  (1) 
range:   Y,  N 

Indicates  whether  or  not  the  target  acoustics  are  those 
required . 

Acquired : 

number  (1),  integer 
range:  0-9 

The  number  of  times  that  the  torpedo  acquired  the 
target.  0  if  it  did  not  acquire  the  target. 

Air  Space: 

char  (5) 
mask:   LL-UU, 

where  LL  is  in  {00... 99}   and   UU  is  in  {01... 99) 
Indicates   the  altitude   range  reserved   in  the   opera- 
tional area    for  participating  aviation  units. 

Brief  Title: 

char  (20) 

The  title  of  the  exercise  brief  to  be  given. 

Cance 1 ed : 

char  (25) 

One  of  6  reasons  why  an  event  was  cancelled  (asset 
availability,  fouled  range,  in trumen ta tion ,  wea- 
ther, no  air  tracking,  no  show). 

Command : 

char  (8) 

The  designation  of  the  command  (  ie  VP-44 ,  SSN-6.80 )  . 

Comments : 

char  (75) 

Narrative  remarks  pertaining  to  the  exercise  and  the 
exercise  results. 

Communications : 
char  (3) 

range:   in   { ' UHF ' ,  ' VHF ' ,  ' HF ' } 

Frequency  range  to  be  used  for  exercise  communications. 
Default:  UHF 
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Compass : 

number  (3),  integer 

range:  000-359 

Measured  in  degrees  true,  except  for  splashpt. 

Heading:   the  heading  of  the  platform  at  TOF . 

Sb:   the  platform's  solution  bearing  to  target. 

Sc  :   the  platform's  solution  course  for  the  target. 

Splashpt:    relative  bearing  of  the  weapon  splash  point 

from  the  target. 
la:        the  course  programmed  into  the  torpedo. 
Tb:    the  true  bearing  from   platform  to  the   target  at 

TOF. 
Tc :  the  true  compass  heading  of  the  target. 
Tm:  the   new   course  of   target  after   it  maneuvers   if 

maneuver  occurs  after   TOF  and  while   torpedo 

is  running  . 

Contact  Code: 
char  (12) 
Indicates  how   the  platform  detected  and  maintained 

contact  with  target  (mad,  difar,  dicass,  ro , 
lofar,  dipper,  surfpass,  surfact,  ir,  vectac, 
spherical,  hull,  towed  array). 

De 1 l very  Code : 
char  (5) 

range:  svtt,  rtt  (asroc),  hover,  flyin,  tt,  asroc 
How  the  torpedo  was  delivered  to  the  splash  point. 

Depth: 

number  (4) 

range:  0-9999 

T:   the  depth  at  which  the  target  is  set  to  run. 

S:   the  depth  at  which  the  torpedo  is  set  to  search. 

Imp:   the   depth  at  which  the   torpedo/ target  imploded 

(set  to  0  if  implosion  depth  is  unknown). 
Water:   the  depth  of  the  water  at  site  of  a  lost  weapon 
or  target. 

Doppler : 

char  (1) 

range:  1-5 

A  code  describing  the  type  and  amount  of  doppler  that 
the  target  has.  [  (1)  >  5kts,  (2)  2.5-5.0kts,  (3) 
2.5-(-2. 5)kts,  (4)  (-2.5)-(-5.0)  kts,  (5)  <  5kts]. 

Eval  : 

char  (10) 

Evaluation  as   to  whether  the  torpedo  hit  the  target. 
(hit,  prob  hit,  prob  miss,  miss,  unknown). 
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Event : 

number  ( 5 ) 

mask:  YYNNN,   where  YY  are    the   last  two  digits  in  the 
year  and  NNN   is  the  sequential  number  of  that 
exercise  conducted  during  that  year. 

The  user-generated  code  identifying  the  specific  exer — 
cise  . 

Exat tain : 

char  (1) 
range:  Y,  N 

Indicates  whether  or  not  the  range  achieved  its  objec- 
tive for  the  exercise,  i.e.,  the  proper  services. 

Exc lusive : 

char  (1) 
range:   Y,  N 

Indicates  whether  or  not  the  event  has  exclusive  use  of 
the  operational  area. 
Exdesc : 

char  (12) 

Narrative  description  of  the  exercise  to  be  conducted. 
Derived  from  exercise  publications. 

Exer  : 

char  (4) 

mask:  ANNN ,  where  A  is  char   and  N  is  digit 
The   designation  of  the  type  of   exercise  to  be  conduc- 
ted.  Derived  from  exercise  publications. 

Frequency : 

char  (2) 
range:   NB,  BB 

Indicates  whether  the  target  is  transmitting  mainly 
narrow  band  ( NB )  or  broad  band  (BB)  sounds.  N/A 
if  designation  is  a  ship. 

Geometry  Code: 
char  (4) 

The  code  for  the  geometry  programmed  into  the  target. 
(N/A  if  designation  is  a  ship  or  submarine). 

Height: 

number  ( 5 ) 
range:  0  -  99,999 

The  height  at  which  the  Mk-46  torpedo  was  launched.  For 
surface  ship,  Height  =  0. 
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Hours : 

number  (2,1) 

range :  . 1  -  99 

Number  of  hours  that  were  lost  for  a  specific   reason 

canceled.  Recorded  as  hours  and  tenths  of  hours. 
Total  of  all  cancelled  hours  can  not  exceed  dif- 
ference between  scheduled  start  time  and  scheduled 
stop  time. 


Kts 


number  (2) 

range:  0-99 

Speed  measured  in  kts. 

Ts:   the  actual  speed  of  the  target  at  TOF. 

Tm:  the  speed  of  the  target  after  maneuver,  if  maneuver 

occurs  after  TOF  and  before  end  of  torpedo  run. 
Ss:  the  platform's  solution  of  speed  for  the  target. 


Lat 


char  (10) 

Template:    dd:mm:ss  N,  where    dd  is  degrees,   mm  min- 
utes, ss  seconds, 
range:   dd  20  -  40 
mm   0-59 
ss   0-59 
The  latitude  at  which  the  target  or  weapon  was   lost. 
All  latitudes  ar&    assumed  to  be  north  (N). 

Launch : 

char  (7) 

The  designation  of  the  launch  vehicle  for  the  exercise 
target.  N/A  if  the  target  is  a  surface  ship  or  an 
actual  submarine. 

Linenumber : 

number  (3),  integer 

Identifies  unique  line  number  of  comments. 

Location : 

char  (20) 

Provides  the  location  of  the  brief. 

Longitude : 

char  (9) 

template  ddd:mm:ss  W 
range:   dd  0  -  180 
mm  0  -  59 
ss  0  -  59 
The  longitude  at  which  the  weapon  or  target  was  lost. 
All  longitudes  are  assumed  to  be  west  (W). 
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Message : 

char  (1) 

range:   Y,  N 

Req :  indicates  whether  or  not  a  "green"  tasking  mes- 
sage needs  to  be  sent  to  the  participants  in  the 
exercise . 

Sent:  if  Req  =  Y,  indicates  whether  or  not  the  tasking 
message  has  been  sent.   N/A  if  Req  =  N. 

Sub:  indicates  whether  or  not  a  submarine  relaxation 
message  is  required  for  the  exercise. 

Minutes : 

number  (2,1) 

range:   0.0  -  60.0 

Maneuver:  the  time  in  minutes  after  TOF  at  which  the 
target  maneuvers.  If  no  maneuver  while  the  torpedo 
is  running  then  0  is  entered.  If  maneuver  occurs 
at  TOF  enter  O.i.  If  0  IS  entered,  skip  target 
maneuver  course  and  speed. 

Recover:  the  number  of  minutes  expended  by  the  reco- 
very vehicle  in  retrieving  the  weapon  following 
the  exercise. 

Search:  the  number  of  minutes  that  the  torpedo  was 
engaged  in  searching  for  the  target. 


Mk  : 


char  (8) 

range:  legal  real/simulated  weapons  or    targets  from 
look  up  tables.  The  mk  of  the  weapon  or  target 


Mod 


char  (5) 

range:  legal  mods  for  the  selected  torpedo 
The  mod  of  the  torpedo. 

Modecode : 

char  (6) 

range:  'snake'  or   circle' 

Mode  the  torpedo  uses  in  its  search. 

Nodrop : 

char  (1) 

range:   a  -  i 

Letter  code  to  indicate  why  the  participant  did  not 
fire  all  of  his  scheduled  weapons.  (a-  platform 
problems,  b-  torpedo  problems,  c-  weather,  d- 
inadequate  recovery  assets,  e-  time  constraints, 
f-  fouled  range  g-  inadequate  TMA,  h-  pinger 
problem,  i-  other). 
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Number : 

number  ( 1 ) 

S:   the  number  of  weapons  scheduled  to  be  dropped. 
U:    the  number  of   units  participating  in   an  exercise 
from  a  given  command. 

Oparea : 

char  (6) 

User-generated  title  for  the  area  in  which  the  exercise 
will  be  conducted. 

Personnel : 

char  (10) 

Brief:   briefer  assigned  to  conduct  designated  brief. 

0a :   operations  analyst  assigned  to  the  exercise. 

Op:   operation  controller  assigned  to  the  exercise. 

Pe :  project  engineer  assigned  to  the  exercise. 

S:   range  safety  officer  assigned  to  the  exercise. 

Ph: 

number  (3) 

range:   0-100 

Percent  rating  of  the  placement  of  the  weapon. 

Pinger : 

char  (4) 

range:   in  {  '  nA  '  ,  'nB',  ' nAnB ' } ,  where  n  is  an  integer 

Indicates  number  of  and  channel (s)  of  pinger(s)  as- 
signed to  a  resource. 

T:  indicates  the  number  and  channel  of  the  pinger  in 
the  target. 

U:  indicates  the  number  and  channel  of  pinger  used  by 
the  participating  user  submarine. 

W:  indicates  the  number  and  channel  of  the  pinger  in 
the  weapon . 

Range : 

number  ( 5 ) 

range:   0  -  99,999 

Measured  in  yards. 

S:   the  platform's  solution  of  the  distance  at  TOF . 

Splashpt:   distance  from  the  splash  point  to  target. 

T:   actual  distance  of  target  from  platform  at  TOF. 

Recovered : 

char  (1) 
range :   Y  ,  N 

Indicates  whether  or  not  the  object  has  been  recovered. 
If  N,  then  the  LOST  object  is  used.  N/A  if  target 
designation  is  a  ship  . 
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Recovery : 

char  (8) 

The   designation  of  the  recovery  vehicle  for  the  object 
(ie  TRW-768  or   HC-1563).   N/A  if   target  designa- 
tion is  a  ship. 
Haulback:   the  designated  weapon  haulback  vehicle. 
Pri:   primary  recovery  vehicle. 
Sec:   secondary  recovery  vehicle. 

Search-seconds : 
number  (3) 
range:   0  -  999 
The  amount  of  time  the  weapon  was  in  its  search  phase. 

Seastate : 

number  ( 1 ) 

range:   0-9 

The  sea  state  as  measured  by  the  beaufort  scale. 

Serial  Number: 
char  (7) 
The  serial  number  of  the  torpedo. 

Showed : 

char  (1) 
range :   Y ,  N 

Used  to  indicate  whether  or  not  the  scheduled  platform 
showed  up  for  the  exercise. 

Sidenumber : 

char  (7) 

The  number  on  the  side  of  an  aircraft  to  uniguely  iden- 
tify it.  Used  only  if  command  is  a  aircraft 
squadron . 

Sonar : 

char  (7) 

range:    active' ,  'passive' ,  'combo' ,  'actpass' 

The  type  of  sonar  detection  used  by  the  torpedo. 

Sonobuoy  no . : 

number  (3) 
range:   0  -  999 

The  number  of  sonobuoys  of  a  particular  type  dropped  by 
a  pi atf orm . 

Sound : 

number  (3) 
range:   0  -  999 

Sound  level  of  target  measured  in  dB;  or,  the  augmenta- 
tion sound  level  if  the  target  is  a  ship. 
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Speed : 

number  (3) 

range:   0  -  500  kts 

Speed  of  the  platform  at  time  of  attack. 

Target  Designation: 

char  (8) 

Indicates  the  type  of  target  used  in  the  exercise. 
Target  Performance: 

char  (20) 

Objective  evaluation   of  target  performance   during  the 
exercise.  ("Did  Not  Run",  "Floater",  etc.). 


Time 


char  (14) 

mask:   ddhhmmZ  MONyy 

Brief:  scheduled  brief  time. 

C:   the  time  an  event  actually  starts  from  the  point  of 

view  of  the  range.  (Default:  sched  start  time). 
F:    the  time  an  event  actually  finishes  from  the  point 

of  view  of  range.  (Default:  sched  finish  time). 
Lost: 


Range:   comex  to  finex 

Time  at  which  the  weapon  or  target  was  lost 
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Range:   comex  to  finex 

Time  at  which  the  target  is  launched. 
MOCS  start:   scheduled  man-up  time  for  range  personnel. 
MOCS  stop:    scheduled   shut-down  time   for  range   per- 
sonnel . 
Schstart:   scheduled  exercise  start  time. 
Schstop:   scheduled  exercise  finish  time. 
Start: 

Def au 1 t :   comex 

Range:   comex  to  finex 

Time  at  which   the  platform  started  searching   for 
the  target  which  resulted  in  this  attack. 
Tof  : 

Default:   Date  part  to  comex. 

Range:   comex  to  finex. 

Time  of  fire  of  a  weapon. 

Torpperf : 

char  (20) 

Indicates  the  performance  of  the  weapon  after  launch. 

(normal  run,   erratic  run,   did  not   run,  sank   at 
launch  point,  sank  at  end  of  run,  damaged). 
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Track  Quality: 
number  (3) 

range:   0  -  100 
The   percent  evaluation  of   the  quality  of   the  range's 
track  of   the  object.  (0  =  no  track,  100  =  perfect 
track ) . 

Tracking  Type: 
char  (1) 

range:   in   {e,  i,  b} 

The   type  of  tracking  to  be  used  during  the  exercise, 
(e  =  EATS,  i  =  in-water,  b  =  both). 

Transponder : 
char  (4) 

range:   IPIP,  SIP,  SAIP 

Indicates   the  type  of  transponder  with  which  the  plat- 
form is  equipped.   N/A  for  submarines. 

Used  : 

char  ( 1 ) 
range:   Y,  N 

Indicates  whether  or  not   a  scheduled  support   platform 
was  used  during  the  event. 

Visible: 

number  (2) 

range:   0-99 

The  visibility  on  the  range  in  nm.  (99  =  unlimited). 
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APPENDIX  D 


DATA  FLOW  DIAGRAMS 
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APPENDIX  E 


UPDATE.  DISPLAY  AND  CONTROL  MECHANISMS 


Schedule  Application 


EXERCISE  OBJECT 
Display  Mechanisms 


I.  Query  on  Exercise 

A.  Output  Description 

-  form   showing  all  data  for  a  given  exercise 
even  t 

B.  Source  Data 

-  EXERCISE  object 

C.  Processing  Notes 

-  EXERCISE   object  contains  USER,  WEAPON,  BRIEF 
and  TARGET  object  data 

D.  Volume 

-  five  per  week 

E.  Frequency 

-  daily,  as  needed 

II.  Weekly  Exercise  Schedule 

A.  Output  Description 

-  ORACLE  report  form  sent  to  all  concerned 

B.  Source  Data 

-  EXERCISE  object 

C.  Processing  Notes 

-  EXERCISE  object  contains  BRIEF,   USER,  WEAPON 
and  TARGET  objects 

D.  Volume 

-  25  per  week 

E.  Frequency 

-  once  per  week 
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III.   Modified  Weekly  Exercise  Schedule 

A.  Output  Description 

-  ORACLE  report  form  sent  to  all  concerned 

-  confirmation  message  on  screen 

B.  Source  Data 

-  current  Weekly  Exercise  Schedule 

-  EXERCISE  object 

-  Exercise  Type  and  Event  Number  keyed  by  PE 

C.  Processing  Notes 

-  BRIEF,  USER,  WEAPON  and  TARGET  objects  con- 
tained within  associated  EXERCISE  object 

D.  Volume 

-  25  per  occurrence 

E.  Frequency 

-  daily,  as  needed 


EXERCISE  OBJECT 
Update  Mechanisms 

Create  Exercise 

A.  Input  Description 

-  list  of  exercises   (from  monthly  planning 
schedule ) 

-  personnel  availability   (from  A-Base ) 

-  range  availability   (from  E-Base) 

-  TARGET  object  data   (from  Project  Manager, 
NUWES ,  and  Supporting  Commands) 

USER  object  data   (from  Project  Manager  and 

NUWES) 

WEAPON  object  data   (from  Project  Manager  and 

Supporting  Commands) 

BRIEF  object  data   (from  Project  Manager) 

B.  Output  Description 

-  new  EXERCISE  object  in  database 

-  new  BRIEF  object  in  database 

-  new  USER  object  in  database 

-  new  WEAPON  object  in  database 

-  new  TARGET  object  in  database 

-  confirmation  message  on  screen 
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C.  Processing  Notes 

-  scheduler  needs  access  to  A-Base  and  E-Base 

D.  Volume 

-  normal  two  exercises  per  day,  five  days  per 
week 

E.  Frequency 

-  once  per  week 

II.  Modify  EXERCISE  Data 

A.  Input  Description 

-  changes  to  monthly  planning  schedule  (from  PM , 
NUWES,  and  Supporting  Commands) 

-  changes  to  personnel  availability   (from  ( A- 
Base) 

-  changes  to  range  availability   (from  E-Base) 

-  changes  to  scheduled  exercise  event   (from  PM , 
NUWES  and  Supporting  Commands) 

B.  Output  Description 

-  modified  EXERCISE  object  in  database 

-  modified  BRIEF  object  in  database 

-  modified  USER  object  in  database 
modified  WEAPON  object  in  database 

-  modified  TARGET  object  in  database 

-  confirmation  message  on  screen 

-  change  notice  sent  to  all  affected 

C.  Processing  Notes 

Project  Engineer  needs  access  to  A-Base  and  E- 
Base 

D.  Volume 

-  two  per  week 

E.  Frequency 

daily,  as  needed 

III.  Add/Edit  BRIEF  data  to  EXERCISE 

-  see  Update  Mechanisms  for  BRIEF 

IV.  Add/Edit  USER  data  to  EXERCISE 

-  see  Update  Mechanisms  for  USER 

V.  Add/Edit  WEAPON  data  to  EXERCISE 

-  see  Update  Mechanisms  for  WEAPON 

VI.  Add/Edit  TARGET  data  to  EXERCISE 

-  see  Update  Mechanisms  for  TARGET 
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VII.   Delete  EXERCISE  Event 

A.  Input  Description 

-  scheduled  exercise  event  to  be  cancelled   (from 
PM ,  NUWES ,  Supporting  Commands,  User) 
EXERCISE  object  in  database 

B.  Output  Description 

-  deletion  of  EXERCISE  object  from  database 

-  deletion  of  associated  BRIEF  objects  from 
database 

-  deletion  of  associated  USER  objects  from  data- 
base 

-  deletion  of  associated  WEAPON  objects  from 
database 

-  deletion  of  associated  TARGET  objects  from 
database 

-  confirmation  message  on  screen 

-  change  notice  sent  to  all  affected 

C .  Vo 1 ume 

-  four  exercises  per  month 

D.  Frequency 

daily,  as  needed 


EXERCISE  OBJECT 
CONTROL  MECHANISMS 

I.   Provide  Password  Requirement  for  Security 

BRIEF  OBJECT 
Display  Mechanisms 

I.   Query  on  BRIEF 

A.  Output  Description 

-  form  showing  all  data  for  a  given  brief 

B.  Source  Data 

-  BRIEF  object  or  EXERCISE  object 

-  Exercise  Type  and  Event  Number  keyed  by  clerk 

C.  Processing  Notes 

-  used  by  scheduler 
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D.  Volume 

-  three  per  week 

E.  Frequency 

-  daily,  as  needed 

II.  Weekly  Briefing  Report 

A.  Output  Description 

-  ORACLE  report  form  sent  to  all  concerned 

B.  Source  Data 

-  BRIEF  object  or  EXERCISE  object 

-  Exercise  Type  and  Event  Number  keyed  by  clerk 

C.  Processing  Notes 

-  sent  to  all  concerned  when  weekly  schedule 
approved 

D.  Volume 

-  25  per  week 

E.  Frequency 

-  once  per  week 

III.  Modified  Weekly  Briefing  Report 

A.  Output  Description 

-  ORACLE  report  form  sent  to  all  concerned 

B.  Source  Data 

-  current  Weekly  Briefing  Report 

-  BRIEF  object  or  EXERCISE  object 

-  Exercise  Type  and  Event  Number  keyed  by  clerk 

C.  Processing  Notes 

sent  to  all  concerned  when  changes  to  schedule 
approved 

D.  Volume 

-  25  per  week 

E.  Frequency 

-  daily,  as  needed 


BRIEF  OBJECT 
Update  Mechanisms 

I .   Create  Brief 

A.   Input  Description 

-   list  of  scheduled  exercises   (from  O-Base ) 


61 


-  list  of  required  briefs  for  scheduled  exercise 
(from  Project  Manager) 

-  room  location  and  availability   (from  E-Base ) 

-  briefer  availability   (from  A-Base) 

B.  Output  Description 

-  new  BRIEF  instance  in  database 

-  new  BRIEF  data  for  weekly  schedule 
new  BRIEF  Weekly  Report 

C.  Processing  Notes 

-  scheduler  needs  access  to  A-Base  and  E-Base 

D.  Volume 

-  minimum  two  briefs  per  exercise 

-  normal  two  exercises  per  day 

E.  Frequency 

-  once  per  week  per  exercise 
I  I  .   Modify  BRIEF  Data 

A.  Input  Description 

-  changes  to  scheduled  events   (from  Project 
Manager,  NUWES,  Users,  Supporting  Commands) 

-  change  to  room  1  oca t ion /avai 1 abi 1 i ty   (from  E— 
Base) 

-  change  in  briefer  availability   (from  A-Base) 

-  change  in  Brief  requirement   (from  Project 
Manager ) 

B.  Output  Description 

-  modified  BRIEF  object  instance  in  database 

-  modified  Weekly  Brief  Report 

C.  Volume 

-  one  per  week 

D.  Frequency 

-  daily,  as  needed 
III .   Delete  BRIEF 

A.  Input  Description 

-  scheduled  exercise  to  be  cancelled   (from 
Project  Manager,  NUWES,  User) 

-  BRIEF  objects  in  database 

B.  Output  Description 

deletion  of  scheduled  briefs  from  database 

-  updated  Weekly  Brief  Report 
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updated  room  availability  in  E-Base 
updated  briefer  availability  in  A-Base 

C.  Processing  Notes 

-  scheduler  needs  access  to  A-Base  and  E-Base 

D.  Volume 

-  two  exercises  per  month 

-  minimum  two  briefs  per  exercise 

E.  Frequency 

-  daily,  as  needed 


BRIEF  OBJECT 


CONTROL  MECHAN I SMS 


I.   Provide  Password  Requirement  for  Security 


USER   OBJECT 
Update  Mechanisms 

Create  USER 

A.  Input  Description 

-  Exercise  Type  and  Event  Number   (from  monthly 
schedu 1 e ) 

-  name  of  user  to  be  scheduled  for  exercise  event 
(from  PM  or  NUWES ) 

-  number  of  units  from  a  given  user  to  be  sched- 
uled for  exercise  event   (from  PM  ,  or  NUWES) 

-  list  of  authorized  users   (from  database) 

B.  Output  Description 

-  new  USER  object  in  database 

C.  Processing  Notes 

this  function  adds  USER  data  to  new  EXERCISE 

-  USER  object  is  created  by  scheduler  as  integral 
part  of  the  EXERCISE  object 

D.  Volume 

-  minimum  one  USER  per  event 

-  normal  10  events  per  week 
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E.   Frequency 

-  once  per  week  per  exercise  event 
I  I .   Modify  USER  Data 

A.  Input  Description 

-  change  in  number  of  units  of  participating 
command 

-  change  in  tracking  equipment  aboard  participa- 
ting unit 

B.  Output  Description 

-  modified  USER  object  in  database 

-  modified  EXERCISE  object  in  database 

-  confirmation  message  on  screen 

-  change  notification  sent  to  all  affected 

C.  Processing  Notes 

-  this  process  changes  USER  data  and,  consequent- 
ly, EXERCISE  data  for  scheduled  event 

-  Project  Engineer  makes  changes  to  USER  object 
when  making  changes  to  associated  EXERCISE 
object 

D.  Volume 

-  one  per  week 

E.  Frequency 

-  daily,  as  required 
III .   Delete  USER 

A.  Input  Description 

-  scheduled  user  to  be  deleted  from  exercise 
event   (from  PM ,  NUWES ,  User  Command) 

-  EXERCISE  object   (from  database) 

-  USER  object   (embedded  in  EXERCISE  object) 

B.  Output  Description 

-  deletion  of  indicated  user  from  exercise  event 
deletion  of  indicated  USER  object  from  database 

-  confirmation  message  on  screen 

-  change  notice  sent  to  all  affected 

C.  Processing  Notes 

-  USER  object  also  deleted  with  deletion  of 
entire  exercise  event  (EXERCISE  object) 
WEAPON  object  (if  any)  should  also  be  deleted 

D.  Volume 

-  two  per  month 
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E.   Frequency 

-   daily,  as  required 


USER   OBJECT 
Display  Mechanisms 

*   USER  object  is  not  normally  displayed  as  a  separate 
entity.  Rather,  it  is  embedded  within  the  associated  EXER- 
CISE object. 


USER  OBJECT 
CONTROL  MECHANISMS 


I.   Provide  Password  Requirement  for  Security 


WEAPON   OBJECT 


Update  Mechanisms 

Create  WEAPON 

A.  Input  Description 

Exercise  Type,  Event  Number  and  Command   (from 
monthly  schedule) 

-  weapon  scheduled  for  exercise  event   (from  PM ) 

-  list  of  authorized  weapons   (from  database) 

B.  Output  Description 

new  WEAPON  object  in  database 

C.  Processing  Notes 

-  WEAPON  object  is  created  by  scheduler  as  an 
integral  part  when  the  USER  object  is  created 

D.  Volume 

-  normal  two  WEAPON  objects  per  user 

-  minimum  one  user  per  event 

-  normal  10  events  per  week 

E.  Frequency 

-  minimum  once  per  week  per  exercise  event 
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II.  Modify  WEAPON  Data 

A.  Input  Description 

-  Exercise  Type,  Event  Number  and  Command 

-  change  in  WEAPON  data   (from  PM  or  Supporting 
Command ) 

-  change  in  USER  data   (from  PM  or  NUWES ) 

B.  Output  Description 

-  modified  WEAPON  object  in  database 

-  modified  USER  object  in  database 
confirmation  message  on  screen 

-  change  notification  sent  to  all  affected 

C.  Processing  Notes 

-  this  process  changes  WEAPON  data  and,  conse- 
quently, USER  object  data  for  a  given  scheduled 
event 

-  Project  Engineer  makes  changes  to  USER  object 
when  making  changes  to  associated  WEAPON  object 

D.  Volume 

-  one  per  week 

E.  Frequency 

-  daily,  as  required 

III.  Delete  WEAPON 

A.  Input  Description 

-  Exercise  Type,  Event  Number,  Command  Name 

-  weapon  to  be  deleted  (Mk) 
USER  object   (from  database) 

WEAPON  object   (embedded  within  USER  object) 

B.  Output  Description 

deletion  of  indicated  weapon(s)  from  exercise 
even  t 

-  deletion  of  indicated  WEAPON  object  from  data- 
base 

-  confirmation  message  on  screen 

-  change  notification  sent  to  all  affected 

C.  Processing  Notes 

-  WEAPON  object  is  also  deleted  with  deletion  of 
entire  exercise  event  (EXERCISE  object)  and 
with  the  deletion  of  a  user  (USER  object)  from 
an  exercise  event 
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D.  Volume 

-  two  per  month 

E.  Frequency 

-  daily,  as  required 


WEAPON   OBJECT 
Display   Mechanisms 

*   WEAPON  object  is  not  normally  displayed  as  a  sepa- 
rate entity.  Rather,  it  is  embedded  within  its  associated 
USER  object. 


WEAPON  OBJECT 
CONTROL  MECHANISMS 


I.   Provide  Password  Requirement  for  Security 


TARGET   OBJECT 


Update  Mechanisms 


Create  TARGET 

A.  Input  Description 

-  Exercise  Type  and  Event  Number   (from  monthly 
schedu le ) 

-  target  to  be  scheduled  for  exercise  event 
(from  PM  or  NUWES ) 

-  list  of  targets   (from  database) 

B.  Output  Description 

new  TARGET  object  in  database 

C.  Processing  Notes 

TARGET  object  is  created  by  scheduler  as  an 
integral  part  when  the  EXERCISE  object  is 
created 

D.  Volume 

minimum  one  TARGET  per  event 
normal  10  events  per  week 
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E.   Frequency 

-  minimum  once  per  week  per  exercise  event 

II.  Modify  TARGET  Data 

A.  Input  Description 

-  Exercise  Type  and  Event  Number 

change  in  Target  data   (from  PM  or  NUWES) 

B.  Output  Description 

-  modified  TARGET  object  in  database 

-  modified  EXERCISE  object  in  database 

-  confirmation  message  on  screen 

-  change  notification  sent  to  all  affected 

C.  Processing  Notes 

-  this  process  changes  TARGET  data  and,  conse- 
quently, EXERCISE  object  data  for  a  given 
scheduled  event 

-  Project  Engineer  makes  changes  to  EXERCISE 
object  when  making  changes  to  associated 
TARGET  object 

D.  Volume 

one  per  week 

E .  Frequency 

-  daily,  as  required 

III.  Delete  TARGET 

A.  Input  Description 

-  Exercise  Type  and  Event  Number 

target  to  be  deleted   (from  PM  or  NUWES) 

-  EXERCISE  object   (from  database) 

-  TARGET  object   (embedded  within  EXERCISE  ob- 
ject) 

B.  Output  Description 

-  deletion  of  indicated  target  from  exercise 
event 

-  deletion  of  indicated  TARGET  object  from  data- 
base 

-  confirmation  message  on  screen 

change  notification  sent  to  all  affected 

C.  Processing  Notes 

-  TARGET  object  is  also  deleted  with  deletion  of 
entire  exercise  event  (EXERCISE  object) 
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D.  Volume 

-  two  per  month 

E.  Frequency 

-  daily,  as  required 


TARGET   OBJECT 
Display  Mechanisms 

*   TARGET  object  is  not  normally  displayed  as  a  sepa- 
rate entity.  Rather,  it  is  embedded  within  its  associated 
EXERCISE  object. 


TARGET  OBJECT 
CONTROL  MECHANISMS 

I.   Provide  Password  Requirement  for  Security 

B.   Results  Application 

OPERATIONS  ANALYST  APPLICATION 
DISPLAY  MECHANISMS 

I.   Monthly /Quarter ly  Reports 

A.  Output  Description 

-  tables  for  monthly  and  quarterly  reports  on 
screen 

-  tables  for  monthly  and  quarterly  reports 

B.  Source  Data 

-  RESULTS  object 

-  user  input  time  period  for  tables 

-  tables  desired 

C.  Processing  Notes 

-  use  menus  to  choose  which  table  to  print  and 
time  period  covered 

D .  Vo lume 

-  two  per  month 
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E.   Frequency 

-  monthly 
I  I  .   TRIMS  Data 

A.  Output  Description 

ASCII  file  for  import  into  DB3+ 

-  screen  showing  TRIMS  data 

B.  Source  Data 

-  RESULTS  object 

C.  Processing  Notes 

-  ensure  all  exercise  entered  into  O-Base  before 
running 

D.  Volume 

-  once  per  month 

E.  Frequency 

-  monthly 
III.   Community  Reports 

A.  Output  Description 

screen  with  summary  data  presented 

-  paper  report  of  community  data 

B.  Source  Data 

-  RESULTS  object 

C.  Processing  Notes 

-  user  selects  time  period  and  community  to  be 
summari  zed 

D.  Volume 

five  per  quarter 

E.  Frequency 

-  quarter  1 y 


OPERATIONS  ANALYST  APPLICATION 


CONTROL  MECHANISMS 


I.  Provide  Password  Requirement  for  Security 
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ENTRY  CLERK  APPLICATION 

PLATFORM  Object 

Update  Mechanisms 


I  .   Create  PLATFORM 

A.  Input  Description 

-  Exercise  Summary 

-  EXERCISE  object 

B.  Output  Description 

-  Exercise  Summary  neat 
new  instance  of  PLATFORM 

-  confirmation  message 

C.  Processing  Notes 

-  Platform  must  correspond  to  event  in  RESULT 

D.  Volume 

-  two  per  event 

E.  Frequency 

-  once  per  day 
I  I  .  Modify  PLATFORM 

A.  Input  Description 

PLATFORM  object  instance  from  database 

-  required  changes 

B.  Output  Description 

-  modified  objects 

-  updated  Event  Summary  neat 

C.  Processing  Notes 

-  any  changes  of  the  data  in  PLATFORM  can  cause 
instances  to  be  deleted  or  changed  from  ATTACK 
obj  ec t 

D.  Volume 

-  two  per  week 

E.  Frequency 

-  weekly 

III.   Add/Edit  ATTACK  to  PLATFORM 

A.   See  Update  Mechanisms  for  ATTACK 
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PLATFORM  OBJECT 
Display  Mechanisms 

I .  Query  on  PLATFORM 

II.  Output  Description 

-  form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

A.  Source  Data 

-  PLATFORM  object 

B.  Processing  Notes 

-  all  data  in  different  objects  must  be  joined 
together 

-  on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 

-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

C.  Volume 

-  four  per  day 

D.  Frequency 

-  daily 

III.  Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  exercise  summary 

-  format  to  be  similar  to  hand  written  exercise 
summary 

B.  Source  Data 

-  PLATFORM  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 

-  for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 

-  12  per  week 

E.  Frequency 

-  dai 1 y 
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PLATFORM  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE,  and  OA . 


ENTRY  CLERK  APPLICATION 

ATTACK  Object 

Update  Mechanisms 


I.   Create  ATTACK  Object 

A.  Input  Description 

-  Exercise  Summary 

-  EXERCISE  object 

B.  Output  Description 

-  Exercise  Summary  neat 

-  new  instance  of  ATTACK 

-  confirmation  message 

C.  Processing  Notes 

an  ATTACK  must  be  associated  with  a  PLATFORM 

D.  Volume 

-  four  per  event 

E.  Frequency 

-  once  per  day 
I  I .   Modify  ATTACK 

A.  Input  Description 

ATTACK  object  instance  from  database 

-  required  changes 

B.  Output  Description 

-  modified  objects 

-  updated  Event  Summary  neat 

C.  Processing  Notes 

any  changes  of  the  data  in  ATTACK  can  cause 
instances  to  be  deleted  from  or  changed  in  LOST 
Object  and/or  WEAPON  RESULTS  Object. 

D.  Volume 

-  two  per  week 
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E .   Frequency 
-   week  1 y 

III.  Add/Edit  LOST  to  ATTACK 

A.   See  Update  Mechanisms  for  LOST  Object 

IV.  Add/Edit  WEAPON  RESULTS  to  ATTACK 

A.   See  Update  Mechanisms  for  WEAPON  RESULTS 


ATTACK  Object 
Display  Mechanisms 


I  .   Query  on  ATTACK 

A.  Output  Description 

-  form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

B.  Source  Data 

-  ATTACK  object 

C.  Processing  Notes 

all  data  in  different  objects  must  be  joined 
together 

-  on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 

-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

D .  Vo 1 ume 

-  four  per  day 

E.  Frequency 

-  dai  1  y 

II.   Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  Exercise  Summary 

-  format  to  be  similar  to  hand  written  Exercise 
Summary 

B.  Source  Data 

-  ATTACK  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 
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-  for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 

-  12  per  week 

E.  Frequency 

-  dai 1 y 


ATTACK  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE  and  OA  . 


ENTRY  CLERK  APPLICATION 

WEAPON  RESULTS  Object 

Update  Mechanisms 


Create  WEAPON  RESULTS  Object 

A.  Input  Description 

-  Exercise  Summary 

-  EXERCISE  object 

B.  Output  Description 

-  Exercise  Summary  neat 

-  new  instance  of  WEAPON  RESULTS 

-  confirmation  message 

C.  Processing  Notes 

a  WEAPON  must  correspond  to  a  TOF  in  ATTACK 

-  if  a  Platform  performs  a  simulated  attack  no 
weapon  results  is  created 

D.  Volume 

-  three  per  event 

E.  Frequency 

-  once  per  day 
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II.  Modify  WEAPON  RESULTS 

A.  Input  Description 

WEAPON  RESULTS  object  instance  from  database 

-  required  changes 

B.  Output  Description 

-  modified  objects 

-  updated  Exercise  Summary  neat 

C.  Processing  Notes 

any  changes  of  the  data  in  WEAPON  RESULTS  can 
cause  instances  to  be  deleted  from  or  changed 
in  LOST  object 

D.  Volume 

-  two  per  week 

E.  Frequency 

-  week  1 y 

III.  Add/Edit  LOST  to  WEAPON  RESULTS 

A.   See  Update  Mechanisms  for  LOST  Object 


WEAPON  RESULTS  OBJECT 
Display  Mechanisms 

Query  on  WEAPON  RESULTS 

A.  Output  Description 

-  form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

B.  Source  Data 

-  WEAPON  RESULTS  object 

C.  Processing  Notes 

all  data  in  different  objects  must  be  joined 
together 

-  on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 

-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

D.  Volume 

-  four  per  day 

E.  Frequency 

-  dai  1  y 
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II.   Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  Exercise  Summary 

-  format  to  be  similar  to  hand  written  Exercise 
Summary 

B.  Source  Data 

-  WEAPON  RESULTS  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 

-  for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 

-  12  per  week 

E.  Frequency 

-  dai 1 y 


WEAPON  RESULTS  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE  and  OA . 


ENTRY  CLERK  APPLICATION 

TARGET  RESULTS  Object 

Update  Mechanisms 


I.  Create  TARGET  RESULTS  Object 

A.  Input  Description 

-  Exercise  Summary 

-  EXERCISE  object 

B.  Output  Description 

-  Exercise  Summary  neat 

-  new  instance  of  TARGET  RESULTS 

-  confirmation  message 
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C.  Processing  Notes 

-  a  target  must  correspond  to  event  in  RESULT 

D.  Volume 

-  one  per  event 

E.  Freguency 

-  once  per  day 

II.  Modify  TARGET  RESULTS 

A.  Input  Description 

TARGET  RESULTS  object  instance  from  database 

-  reguired  changes 

B.  Output  Description 

-  modified  objects 

C.  Updated  Exercise  Summary  neat 

D.  Processing  Notes 

any  changes  of  the  data  in  TARGET  RESULTS  can 
cause  instances  to  be  deleted  from  or  changed 
in  LOST  object 

E.  Volume 

-  two  per  week 

F.  Freguency 

-  weekly 

III.  Add/Edit  LOST  to  TARGET  RESULTS 
A.   See  Update  Mechanisms  for  LOST 


TARGET  RESULTS  OBJECT 


Display  Mechanisms 

Query  on  TARGET  RESULTS 

A.  Output  Description 

-  form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

B.  Source  Data 

-  TARGET  RESULTS  object 

C.  Processing  Notes 

-  all  data  in  different  objects  must  be  joined 
together 

-  on  guerying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 
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-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

D.  Volume 

-  four  per  day 

E.  Frequency 

-  dai ly 

II.   Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  Exercise  Summary 

-  format  to  be  similar  to  hand  written  Exercise 
Summary 

B.  Source  Data 

-  TARGET  RESULTS  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 

-  for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 

-  12  per  week 

E.  Frequency 

-  dai 1 y 


TARGET  RESULTS  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE  and  OA . 


ENTRY  CLERK  APPLICATION 

LOST  Object 

Update  Mechanisms 


I  .   Create  LOST 

A.   Input  Description 

-  Exercise  Summary 

-  EXERCISE  object 
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B.  Output  Description 

Exercise  Summary  neat 

-  new  instance  of  LOST 

-  confirmation  message 

C.  Processing  Notes 

-  a  LOST  must  correspond  to  a  MK  and  Serial  in 
WEAPON  RESULTS  or  TARGET  RESULTS 

D.  Volume 

four  per  year 

E.  Frequency 

-  once  per  quarter 
I  I .  Modify  LOST 

A.  Input  Description 

-  LOST  object  instance  from  database 

-  required  changes 

B.  Output  Description 

-  modified  objects 

-  updated  event  summary  neat 

C.  Processing  Notes 

any  changes  of  the  data  in  WEAPON  RESULTS  or 
TARGET  RESULTS  can  cause  instances  to  be  de- 
leted or  changed  from  LOST  object 

D.  Volume 

-  four  per  year 

E.  Frequency 

-  semi-annually 


LOST  OBJECT 
Display  Mechanisms 

Query  on  LOST 

A.  Output  Description 

-  form  showing  all  data  for  a  given  event 

-  same  form  as  for  input  of  data 

B.  Source  Data 

-  LOST  object 

C.  Processing  Notes 

-  all  data  in  different  objects  must  be  joined 
together 
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-  on  querying  a  multi-valued  field  must  show  or 
indicate  other  occurrences 

-  on  querying  a  non-key  field  must  indicate  other 
occurrences 

D.  Volume 

-  two  per  month 

E.  Frequency 

-  monthly 

II.   Exercise  Summary  neat 

A.  Output  Description 

-  computer  printed  exercise  summary 

-  format  to  be  similar  to  hand  written  exercise 
summary 

B.  Source  Data 

-  LOST  object 

C.  Processing  Notes 

-  used  by  Program  Engineer  to  check  data  and 
paper  record 

-  for  each  new  instance  and  modified  instance  one 
is  made 

D.  Volume 

-  12  per  week 

E.  Frequency 

-  dai 1 y 


LOST  OBJECT 
Control  Mechanisms 

I.  Provide  Password  Requirement  for  Security. 

II.  In  query  mode  no  changes  can  be  made  and  is  available 
only  to  PE,  and  OA . 
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APPENDIX  F 


RELATION  DIAGRAMS 


A.    Schedule  Application 
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B.    Results  Application 
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APPENDIX  G 


LOGICAL  MENU  STRUCTURE 


A.    SCHEDULE  APPLICATION 


f 

MAIN  MENU 

j 

SCHEDULE 
APPLICATION 

RESULTS 
APPLICATION 

EVE 

> 
NT 

-< 

BR 

EF 

j 

US 

ER 

WE  A 

PON 

-. 

TARGET 

■ 

r 

PRINT 

' 

■  -> 

fK\j\j 

SCHEDULE 

* 

r                                      1 

MODIFY 

r     BRIEF 
REPORT 

i 

DELETE 

*. 

\ 

> 

(~\\  in  n\/ 

UU 

/ 
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B.  RESULTS    APPLICATION 


MAIN  MENU 


SCHEDULE 

APPLICATION 

- 

i 

RESULTS 
APPLICATION 

RESULT 

PLATFORM 

ATTACK 

WEAPONR 

TARGE  TR 

• 
L08T 

'              - 
PRINT 

ADD 

MODIFY 

DELETE 

u 

uc 

HI 
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APPENDIX  H 


ORACLE  TABLES 


A.   APPLICATION  TABLES 


EXERCISE   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

EXDESC 

SSTART 

SSTOP 

MSTART 

MSTOP 

OPAREA 

TRACKTYPE 

PROJENG 

OPCON 

OPANAL 

SAFEOFF 

TPRIREC 

TSECREC 

WPRIREC 

WSECREC 

HAULBACK 

GRNREQ 

GRNSENT 

SUBRLX 

AIRSPACE 

COMM 

EXCLUS 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
CHAR(12) 
CHAR( 14) 
CHAR( 14) 
CHAR( 14) 
CHAR( 14 ) 
CHAR(6) 
CHAR( 1 ) 
CHAR( 10) 
CHAR( 10) 
CHAR (10) 
CHAR( 10) 
CHAR(7) 
CHAR(7) 
CHAR (7 ) 
CHAR(7) 
CHAR(7) 
CHAR(1 ) 
CHARd  ) 
CHAR( 1 ) 
CHAR(5) 
CHAR(3) 
CHAR( 1 ) 
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SCH  COMMENT   TABLE 


Name 


Nul  1? 


Type 


EXER 
EVENT 
LINENO 
COMMENTS 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
NOT  NULL  NUMBER(3) 
CHAR (75) 


BRIEF   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

TITLE 

TIME 

LOCATION 

BRIEFER 


NOT  NULL  CHAR(4) 

NOT  NULL  NUMBER(5) 

NOT  NULL  CHAR (20) 

CHAR( 14 ) 

CHAR (20) 

CHAR( 10) 


TARGET   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

TGTDESIG 

GEOMETRY 

ACOUSTICS 

TPINGER 

LNCHVEH 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
NOT  NULL  CHAR(8) 
CHAR(4) 
CHAR(l) 
CHAR(4) 
CHAR(8) 
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USER   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

COMMAND 

UNUMBER 

TRANSPONDER 

UPINGER 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
NOT  NULL  CHAR(8) 

NUMBER ( 1 ) 

CHAR(4) 

CHAR(4) 


WEAPON   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

MK 

COMMAND 

SNUMBER 

WPINBER 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
NOT  NULL  CHAR (5) 
NOT  NULL  CHAR(8) 

NUMBER ( 1 ) 
CHAR(4) 


RESULT   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

EXDESC 

COMEX 

FINEX 

SSTART 

SSTOP 

OPAREA 

VISIBLE 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
CHAR( 12) 
CHAR( 14) 
CHAR( 14) 
CHAR( 14) 
CHAR(14) 
CHAR(6) 
NUMBER(2) 
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SEASTATE 


EXCOMMENTS   TABLE 


NUMBER ( 1 ) 


Name 


Null?     Type 


EXER 
EVENT 
LINENO 
COMMENTS 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
NUMBER(3) 
CHAR (75) 


CLASSCMTS   TABLE 


Name 


Nul  1? 


Type 


EXER 
EVENT 
LINENO 
COMMENTS 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
NUMBER (3) 
CHAR (75) 


SUPPORT   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

SPLATPORM 

SSIDENO 

USED 


NOT  NULL  CHAR(4) 

NOT  NULL  NUMBER(5) 

CHAR(8) 

CHAR(7) 

CHAR( 1 ) 
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CANCEL   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

CANCEL 

HOURLOST 

CANCELTIME 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER* 5) 
CHAR (25) 
NUMBER(2, 1 ) 
CHAR( 14) 


PLATFORM   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

COMMAND 

SIDENO 

SHOWED 

TRACKQP 

LOFAR 

DIFAR 

DICAS 

VLAD 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
CHAR (8) 
CHAR(7) 
CHAR( 1 ) 
NUMBER(3) 
NUMBER(3) 
NUMBER(3) 
NUMBER(3) 
NUMBER(3) 


SCHWEP   TABLE 


Name 


Nul  1? 


Type 


EXER 

EVENT 

COMMAND 

SIDENO 

WEAPON 

SNUMBER 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
CHAR(8) 
CHAR(7) 
CHAR(5) 
NUMBER(2) 
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NODROP 


CHAR( 1) 


ATTACK   TABLE 


Name 


Null? 


Type 


EXER 

EVENT 

TOF 

COMMAND 

SIDENO 

STARTOP 

TGTCOURSE 

TGTBY 

TGTSPEED 

TGTRANGE 

TGTDEPTH 

TGTMANTIME 

TGTMANCOURSE 

TGTMANSPEED 

SBY 

SCOURSE 

SSPEED 

SRANGE 

HEADTOF 

SPEEDTOF 

ALTITUDE 

MODECODE 

SONARSET 

CONTACT 

DELIVERY 

SPLASHBY 

SPLASHRH 

ACQUIRED 

ATTACKEVAL 

SEARCHDEPTH 

DOPPLER 

PH 


NOT  NULL  CHAR(4) 
NOT  NULL  NUMBER(5) 
CHAR (14) 
CHAR(8) 
CHAR(7) 
CHAR( 14) 
NUMBER(3) 
NUMBER(3) 
NUMBER(2) 
NUMBER(5) 
NUMBER(4) 
NUMBER (2,1 ) 
NUMBER(3) 
NUMBER(2) 
NUMBER(3) 
NUMBER(3) 
NUMBER(2) 
NUMBER(5) 
NUMBER(3) 
NUMBER(3) 
NUMBER(5) 
CHAR(6) 
CHAR(7) 
CHAR( 12) 
CHAR(5) 
NUMBER(3) 
NUMBER ( 5) 
CHAR(1 ) 
CHAR( 10) 
NUMBER(4) 
CHAR ( 1 ) 
NUMBER ( 1,2) 
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ATTCOMMENTS   TABLE 


Name 


Nul  1? 


Type 


TOF 

LINENO 

COMMENTS 


NOT  NULL  CHAR (14) 
NUMBER(3) 
CHAR (75) 


WEAPONR   TABLE 


Name 


Nul  1? 


Type 


TOF 

MK 

SERIAL 

MOD 

TORPPERF 

SEARCHT 

WEPREC 

RECVEH 

RECTIME 

BBVEH 

TRACKQW 


CHAR( 14) 

CHAR(5) 

CHAR(7) 

CHAR(5) 

CHAR (20) 

NUMBER(3) 

CHAR( 1 ) 

CHAR(8) 

NUMBER(2) 

CHAR(8) 

NUMBER(3) 
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LOST   TABLE 

Name  Nu 1 1 ?     Type 

MK  CHAR(5) 

SERIAL  CHAR(7) 

TOF  CHAR (14) 

EXER  CHAR(4) 

EVENT  NUMBER(5) 

MOD  CHAR(5) 

LAT  CHAR(IO) 

LONGITUDE  CHAR (10) 

IMPLOSION  NUMBER(4) 

WDEPTH  NUMBER* 5) 

1 IMELOSS  CHAR( 14) 

FROMBLOCK  CHAR ( 1 ) 


TARGETR   TABLE 

Name  Nu 1 1?     Type 

EXER  CHAR(4) 

EVEN!  NUMBER(5) 

TGTDESIG  CHAR(8) 

SERIAL  CHAR(7) 

TGTPERF  CHAR (20) 

GEOMETRY  CHAR(4) 

TOF  CHAR(14) 

TGTREC  CHAR(l) 

RECVEH  CHAR(8) 

DB  NUMBER(3) 

FREQ  CHAR(2) 

TRACKQT  NUMBER(3) 

MOD  CHAR(5) 
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B.   LOOK-UP  TABLES 


Name 
CANCELLOOKUP 


CANCELLOOKUP 

Nu 11?     Type 


CHAR (25) 


CANCEL   (Legal  Values) 

ASSET  AVAILABILITY 
FOULED  RANGE 
INSTRUMENTATION 
WEATHER 

NO  AIR  TRACKING 

NO  SHOW 


CONTACTLOOKUP 


Name 
CONTACT 


Null?     Type 


CHAR( 12) 


CONTACT   (Legal  Values) 


MAD 

DIFAR 

DICASS 

RANGE  ONLY 

LOFAR 

DIPPER 

SURFPASS 


SURFACT 

IR 

VECTAC 

SPHERICAL 

HULL 

TOWED  ARRAY 
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DELIVERYLOOKUP 


Name 
DEL  IV 


Nu 11?     Type 


CHAR(5) 


DELIVERY    (Legal  Values) 

SVTT 

RTT 

HOVER 

FLYIN 

TT 

ASROC 


Name 


EVALLOOKUP 

Null? 


Type 


EVAL 


CHAR( 10) 


EVAL    (Legal  Values) 

HIT 

PROB  HIT 
PROB  MISS 
MISS 
UNKNOWN 
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Name 


LINENUMBER 

Nul  1? 


Type 


TABLENAME 
EXER 
EVENT 
LINENO 


CHAR( 15) 
CHAR(4) 
CHAR(5) 
NUMBER(3) 


TABLENAME 


EXER  EVENT   LINENO 


SCH_COMMENT 
SCH_COMMENT 
SCH_COMMENT 
SCH  COMMENT 


A601  89004 

A601  89005 

A612  88082 

S610  89001 


1 
1 
7 
1 


Name 


PERFLOOKUP 

Nul  1? 


Type 


PERF 


CHAR (20) 


PERF   (Legal  Values) 

NORMAL  RUN 

ERRATIC  RUN 

DID  NOT  RUN 

SANK  AT  LAUNCH  POINT 

SANK  AT  END  OF  RUN 

DAMAGED 

SEE  COMMENTS 
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Name 
RECOV 


RECOVLOOKUP 

Null? 


Type 


CHAR (4 ) 


RECO   (Legal  Values) 

TWR 
HC-1 


SONARLOOKUP 


Name 


Null?     Type 


SONAR 


CHAR(7) 


SONAR    (Legal  Values) 

ACTIVE 
PASSIVE 
COMBO 
ACTPASS 
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APPENDIX  I 
VARIABLE  ASSOCIATIONS 


Descriptive  Name 


EXERCISE  OBJECT 


Domain  Name 


Variable  Name 


Exercise  Type 
Event  Number 
Exercise  Description 
Schedule  Start  Time 
Schedule  Stop  Time 
MOCS  Start  Time 
MOCS  Stop  Time 
Operational  Area 
Exclusive  Use 
Primary  Target 

Recovery  Vehicle 
Secondary  Target 

Recovery  Vehicle 
Primary  Weapon 

Recovery  Vehicle 
Secondary  Weapon 

Recovery  Vehicle 
Weapon  Haulback 

Vehic le 
Tracking  Type 
Project  Engineer 
Operation  Controller 
Operation  Analyst 
Safety  Officer 
Green  Reguired 
Green  Sent 
Submarine  Relaxation 

Message 
Air  Space 
Commun  ications 
Commen  ts 


BRIEF: 
USERS: 
TARGET: 
RESULTS 


BRIEF  obje 
USER  objec 
TARGET  obi 
RESULTS  ob 


Exer  EXER 

Event  EVENT 

Exdesc  EXDESC 

Time-Schstart  SSTART 

Time-Schstop  SSTOP 

Time-MOCS  Start  MSTART 

Time-MOCS  Stop  MSTOP 

Oparea  OPAREA 

Exclusive  EXCLUS 

Recovery-Pri  TPRIREC 

Recovery-Sec  TSECREC 

Recovery-Pri  WPRIREC 

Recovery-Sec  WSECREC 

Recovery-Haulback  HAULBACK 

Tracking  Type  TRACKTYPE 

Personnel-Pe  PROJENG 

Personnel-Oc  OPCON 

Personnel-Oa  OPANAL 

Personnel-So  SAFEOFF 

Message-Reg  GRNREQ 

Message-Sent  GRNSENT 

Message-Sub  SUBRLX 

Air  Space  AIRSPACE 

Communications  COMM 

Comments  COMMENTS 

ct ;  MV 

t;  MV 

ect;   MV 

jec  t 
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Descriptive  Name 


BRIEF  OBJECT 

Domain  Name 


Variable  Name 


Brief  Title 
Brief  Time 
Location 
Briefer 


Brief  Title 
Time-Brief 
Location 
Personnel -Brief 


TITLE 
TIME 

LOCATION 
BRIEFER 


Descriptive  Name 


USERS  OBJECT 


Domain  Name 


Variable  Name 


Exercise  Type 

Event  Number 

Command  Name 

Number  of  Units 

EATS  Transponder 

Pinger  Channel 

WEAPON:   WEAPON  object 


Exer 

Event 

Command 

Number-U 

Transponder 

Pinger-U 

MV 


EXER 

EVENT 

COMMAND 

UNUMBER 

TRANSPONDER 

UPINGER 


Descriptive  Name 


TARGET  OBJECT 

Domain  Name 


Variable  Name 


Exercise  Type 

Event  Number 

Target  Designation 

Geometry 

Acoustics 

Pinger 

Launch  Vehicle 


Exer 

Even  t 

Target  Designation 

Geometry  Code 

Acoustics 

Pinger-T 

Launch 


EXER 

EVENT 

TGTDESIG 

GEOMETRY 

ACOUSTICS 

TPINGER 

LNCHVEH 


Descriptive  Name 


WEAPON  OBJECT 

Domain  Name 


Variable  Name 


Mk 

Command  Name 

Number  Scheduled 

Pinger 


Mk 

Command 
Number-S 
Pinger-W 


MK 

COMMAND 
SNUMBER 
WPINGER 
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RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Variab le  Name 


Exerc  i 

Event 

Exerci 

Exerci 

Comex 

Finex 

Schedu 

Schedu 

Operat 

Visibi 

Sea  St 

Reason 

Hours 

Cancel 

Suppor 

Suppor 

Suppor 

Classi 

Unc 1  as 


se  Type 

Exer 

Number 

Event 

se  Description 

Exdesc 

se  Attainment 

Exa ttain 

Time-C 

Time-F 

led  Start  Time 

Time-Sens tart 

led  Stop  Time 

Time-Schstop 

ional  Area 

Oparea 

lity 

Visible 

ate 

Seastate 

Canceled     MV 

Canceled 

Lost           MV 

Hours 

Start  Time   MV 

Time-Cancel 

t  Platform    MV 

Command 

t  Side  Number  MV 

Sidenumber 

t  Used         MV 

Used 

tied  Comments 

Commen  ts 

sified  Comments 

Comments 

EXER 

EVENT 

EXDESC 

EXATTAIN 

COMEX 

FINEX 

SSTART 

SSTOP 

OPAREA 

VISIBLE 

SEASTATE 

CANCEL 

HOURLOST 

CANCELTIME 

SPLATFORM 

SSIDENO 

USED 

COMMENTS 

COMMENTS 


PLATFORM;  PLATFORM  object;  MV 

TARGET  RESULTS;  TARGET  RESULTS  object;  MV 


PLATFORM  OBJECT 


Descriptive  Name 


Domain  Name 


Variable  Name 


Exercise  Type 

Event  Number 

Command  Name 

Side  Number 

Showed  Up 

Track  Quality 

Lof  ar 

Dif  ar 

Dicass 

VI  ad 

Weapon  Assigned   MV 

Number  of  Weapons 

Scheduled      MV 
No  Drop  MV 

ATTACK;  ATTACK  object; 


Exer 

Even  t 

Command 

Sidenumber 

Showed 

Track  Quality 

Sonobuoy  no. 

Sonobuoy  no. 

Sonobuoy  no. 

Sonobuoy  no. 

Mk 

Number — S 
Nodrop 


EXER 

EVENT 

COMMAND 

SIDENO 

SHOWED 

TRACKQP 

LOFAR 

DIFAR 

DICAS 

VLAD 

WEAPON 

SNUMBER 
NODROP 


MV 
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TARGET  RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Variable  Name 


Exercise  Type 

Event  Number 

Target  Designation 

Mod 

Serial  Number 

Target  Performance 

Geometry 

Launch  Time 

Target  Recovered 

Recovery  Vehicle 

Sound  Level 

Freguency 

Track  Quality 

LOST;  LOST  object 


Exer  EXER 

Event  EVENT 
Target  Designation     TGTDESIG 

Mod  MOD 

Serial  Number  SERIAL 
Target  Performance     TGTPERF 

Geometry  Code  GEOMETRY 

Time-L  TOF 

Recovered  TGTREC 

Recovery  RECVEH 

Sound  DB 

Freguency  FREQ 

Track  Quality  TRACKQT 


WEAPON  RESULTS  OBJECT 


Descriptive  Name 


Domain  Name 


Variable  Name 


Time  of  Fire 
Mk 
Mod 

Serial  Number 
Torpedo  Performance 
Search  Time 
Weapon  Recovered 
Recovery  Vehicle 
Recovery  Time 
Bring  Back  Vehicle 
Track  Quality 
LOST;  LOST  object 


TOF 

Mk 

Mod 

Serial  Number 

Torpper f 

Search-Seconds 

Recovered 

Recovery 

Minutes-Recover 

Recovery 

Track  Quality 


TOF 

MK 

MOD 

SERIAL 

TORPPERF 

SEARCH 

WEPREC 

RECVEH 

RECTIME 

BBVEH 

TRACKQW 


Descriptive  Name 


LOST  OBJECT 

Domain  Name 


Variable  Name 


Mk 

Mod 

Serial  Number 

Time  Lost 

Latitude 

Longi  tude 

Implosion 

Water  Depth 


Mk 

Mod 

Serial  Number 

Time-Lost 

Lat 

Long 

Depth-Imp 

Depth-Water 


MK 

MOD 

SERIAL 

TIMELOST 

LAT 

LONGITUDE 

IMPLOSION 

WDEPTH 
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ATTACK  OBJECT 


Descriptive  Name 


Domain  Name 


Variable  Name 


Time  of  Fire 
Command  Name 
Side  Number 
Start  Op 

Actual  Target  Course 
Actual  Target  Bearing 
Actual  Target  Speed 
Actual  Target  Range 
Actual  Target  Depth 
Target  Maneuver  Time 
Target  Maneuver 

Course 
Target  Maneuver 

Speed 
Target  Doppler 
Solution  Bearing 
Solution  Course 
Solution  Speed 
Solution  Range 
Heading  at  TOF 
Speed  at  TOF 
Altitude 
Mode 

Sonar  Setting 
Contact  Type 
Delivery  Method 
Bearing  to  Splash  Point 
Range  to  Splash  Point 
Acquired 
Eval  of  Attack 
Search  Depth 
Comments  MV 

Line  Number      MV 
WEAPON  RESULTS;  WEAPON 


Time-Tof 

Command 

Sidenumber 

Time-Start- time 

Compass-Tc 

Compass-Tb 

Kts-Ts 

Range-T 

Depth-T 

Minutes-Maneuver 

Compass-Tm 

Kts-Tm 
Doppler 
Compass-Sb 
Compass-Sc 
Kts-S 
Range-S 

Com pass -Heading 
Speed 
Height 
Modecode 
Sonar 

Contact  Code 
Delivery  Code 
Compass-Splashpt 
Range-Splashpt 
Acquired 
Eval 
Depth-S 
Commen  ts 
Linenumber 
RESULTS  object; 


TOF 

COMMAND 

SIDENO 

STARTOP 

TGTCOURSE 

TGTBY 

TGTSPEED 

TGTRAN6E 

TGTDEPTH 

TGTMANTIME 

TGTMANCOURSE 

TGTMANSPEED 

TGTDOPLER 

SBY 

SCOURSE 

SSPEED 

SRANGE 

HEADTOF 

SPEEDTOF 

ALTITUDE 

MODECODE 

SONARSET 

CONTACT 

DELIVERY 

SPLASHBY 

SPLASHRH 

ACQUIRED 

ATTACKEVAL 

SEARCHDEPTH 

COMMENTS 

LINENO 
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APPENDIX  J 
SCREEN  DESIGNS 


A.   SCHEDULE  APPLICATION 


!                INPUT  NEM  EVENT  DATA 

!         !  EXERCISE  TYPE:       EVENT  NUMBER: 

!        !    EXERCISE  DESCRIPTION:             ! 

!                  EXERCISE  TIMES: 

!   SCHEDULED  START:             SCHEDULED  FINISH: 

!     MOCS  MAN-UP:              MOCS  SHUT-DONN: 

i                EXERCISE  PERSONNEL: 
!              PROJECT  EN6INEER: 

!             OPERATION  CONTROL: 

!             OPERATION  ANALYST: 

!               SAFETY  OFFICER: 

1  0Ff RATIONAL  ARIA  AiiJINIDi  .          EXCLUSIVE  U8E?i 

MISCELLANEOUS  EVENT  DATA 

!  EXERCISE  TYPE:  EVENT  NUMBER:  J 

TRACKING  TYPE:  _ 

EVENT  MESSAGES: 
6REEN  REQUIRED?:  _      6REEN  SENT?:  _ 

SUBMARINE  RELAXATION  MESSAGE  REQUIRED?:  _ 

AIR  SPACE  RESTRICTIONS:  

COMMUNICATIONS: 
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EVENT  SUPPORT  VEHICLES 


+--+• 


-♦--♦ 


EXERCISE  TYPE-, 


EVENT  NUMBER: 


TAR6ET  SUPPORT  VEHICLES: 

PRIMARY  TAR6ET  RECOVERY:  

SECONDARY  TARGET  RECOVERY:  


WEAPON  SUPPORT  VEHICLES: 

PRIHARY  WEAPON  RECOVERY:  

SECONDARY  WEAPON  RECOVERY:  

WEAPON  HAULBACK:  


INPUT  EXERCISE  BRIEF  DATA 

EXERCISE  TYPE:  EVENT  NUNBER:  

TITLE  OF  BRIEF: 

TIME: 

LOCATION: 

BRIEFER: 
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1 
1 

ENTER  USER  DATA 

!  EXERCISE  TYPE  J          EVENT  NUHBER: 

i    i 
i    i 

NAME  OF  COMMAND; 

NUHBER  OF  UNITS!  __ 

PIN6ER  CHANNEL:  . 

(IF  SUBMARINE) 

TRANSPONDER-EQUIPPED?: 

(IF  AIR  OR  SURFACE) 

TYPE  OF  WEAPON       NUMBER 

PIN6ER 

(MK)          SCHEDULED 

CHANNEL 

!               ENTER  TAR6ET  DATA  ! 

♦ ♦ 


EXERCISE  TYPEs 
TARGET  DESI6NATI0N:  . 
PROPER  ACOUSTICS?: 


EVENT  NUMBER;  

6E0METRY  CODE: 
FINGER  CHANNEL: 


TARGET  LAUNCH  VEHICLE: 


+ + 


COMMENTS 


COMMENTS 
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B.   RESULTS  APPLICATION 


EXERCISE   S  U  H  H A  R  Y 

EXERCISE      EVENT       EXERCISE  DESCRIPTION 

OPAREA 

COHEX                  VISIBILITY 

FINEX                  SEA  STATE 

REASON  CANCELED         HOURS   TINE  OF 

LOST   CANCELLATION 

LAUNCH/RECOVERY  ASSETS 
PLATFORM    SIDE  NUMBER   USED 

USER   DATA 


!  EXERCISE 

COMMAND  DESIGNATION 

SIDE  NUMBER 

!     SHOWED  FOR  EXERCISE 

TRACK  QUALITY  

!     SONOBOUY  USA6E:  LOFAR 

i               DIFAR 

DICAS 

!               VLAD   _ 

1         WEAPON  TYPE    NUMBER 

REASON 

i                   SCHEDULED 

NOT  DROPPED 
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ATTACK   DATA 


EXERCISE 


COMMAND 


SIDE  NUMBER 


TOF 


START  ATTACK  RUN  

+ 

SOLUTION  DATA   |    FIRING  UNIT  DATA 


TAR6ET  DATA 

COURSE 
BEARING 

RAN6E 
SPEED 
DEPTH 


COURSE 
BEARING 
RAN6E 
SPEED 


COURSE 

SPEED 

ALTITUDE 


+— 
DOPPLER 


MANEUVER: 
TIME 


+- 
COURSE 
SPEED 


ATTACK   DATA 


+ 

!  EXERCISE  

UNIT 

SIDE  NUMBER      TOF 

+ 

!   FIRING  DATA 

RESULTS 

i  CONTACT  TYPE 

ACQUIRED 
ATTACK  EVAL 

!  ATTACK  MODE 

!  SONAR  SETTIN6 

PH          _ 
SPLASH  BEARING 

!  DELIVERY  MODE  _ 

!  SEARCH  DEPTH   _ 

SPLASH  RANGE 

ATTACK  COMMENTS! 
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WEAPON   DATA 


'.EXERCISE         UN 

IT       SIDE  NUMBER       TOF 

HK  

!   TRACK  QUALITY 

NOD       SERIAL 
TORPEDO  PERFORNANCE 

!     SEARCH  TINE 

WEAPON  RECOVERED(Y,N) 

RECOVER  VEHICLE 

!     TINE  TO  RECOVER 

BRIN6  BACK  VEHICLE 

TARGET   DATA 


EXERCISE 


TAR6ET  DESIGNATION 
LAUNCH  TINE 
PERFORNANCE 
SOUND  LEVEL 
RECOVERED(Y,N) 


NOD 


SERIAL  NUNBER 
TRACK  QUALITY 
6E0HETRY 
FREQUENCY  BAND 
RECOVERY  VEHICLE 


LOST      T  A  R  6  E  T  S     AND      WEAPONS 


!  EXERCISE          NK 

HOD  

SERIAL  NUNBER 

!               TOF 

!     TINE  OF  LOSS 

!     LATITUDE 

L0N6ITUDE 

!     IMPLOSION  DEPTH 

1     WATER  DEPTH 
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UNCLASSIFIED         C0HHENT8 


!    EXERCISE 
♦- 

i      COMMENTS 


CLASSIFIED     COKHENTS 


i    EXERCISE 
+ — 

!  COMMENTS 
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APPENDIX  K 
SYSTEM  USER  MANUAL 


In  troduc  t ion ; 

This  manual  introduces  and  explains  the  operation  of 
the  two  O-Base  applications.  These  applications  are  de- 
signed to  minimize  the  effort  required  for  data  entry.  They 
also  provide  the  ability  to  modify,  delete  and  query  the 
database.  The  Schedule  application  stores  the  event  data 
that  make  up  the  schedule,  and  provides  an  easy  method  for 
making  changes  to  the  event  data  as  circumstances  change  or 
more  information  becomes  available.  The  Results  application 
stores  information  about  what  occurred  during  an  event.  This 
information  can  then  be  queried  or  used  to  produce  various 
reports . 

About  This  Manual; 

This  manual  is  designed  to  guide  you  to  in  using  the 
system.  It  assumes  that  you  have  completed  the  SQL*FORMS 
Operator's  Guide  tutorial,  and  are  familiar  with  the  various 
terms  used  in  that  manual.  If  you  are  unfamiliar  with  the 
terms  block,  record,  form  and  query,  refer  to  the  SQL*FORMS 
Operators' s  Guide. 

This  user  manual  contains  two  parts,  Part  I  covers  the 
Schedule  application  and  Part  II  the  Results  application. 
Each  part  is  divided  into  seven  sections:  1)  Introduction, 
2)  Description  of  the  form,  3)  Add  procedures,  4)  Modify 
procedures,  5)  Delete  procedures,  6)  Querying  the  database, 
and  7)  Detailed  description  of  each  field.  The  most  useful 
section  will  be  the  detailed  field  descriptions,  because  it 
describes  how  each  field  operates.  This  section  should  be 
kept  handy  as  a  reference  even,  for  experienced  operators. 

Conventions  and  General  Operating  Procedures: 

•  When  a  function  key  is  described  in  the  manual,  the 
Oracle  name  will  be  given  first,  followed  by  the 
IBM/MS-DOS  keyboard  name  enclosed  in  <  >. 

•  When  entering  data  into  a  field,  a  Next  Field  <Enter> 
moves  the  cursor  to  the  next  available  field. 

•  When  entering  a  field,  a  short  help  message  appears  at 
the  bottom  of  the  screen. 
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Starting  the  Applications: 

To  start  the  application,  make  sure  that  Oracle  was 
started  properly.  Then,  type  either  Schedule  or  Results 
followed  by  a  carriage  return  <cr>.  This  will  start  the 
appropriate  application.  You  will  then  be  asked  for  your 
name  and  password.  Enter  your  name  and  password  followed  by 
a  carriage  return  <cr> .  If  you  do  not  have  or  forget  your 
password  see  your  Database  Administrator. 
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PART  I    SCHEDULE   APPLICATION 


1 .  Introduc tion ; 

This  application  stores  each  scheduled  event  into  the 
database  so  that  a  schedule  can  be  constructed.  The  proce- 
dure for  entering  data  has  been  made  as  simple  as  possible. 
You  type  in  the  data  you  wish  to  enter  and  then  press  the 
Enter  <cr>  key.  The  most  important  information  entered  is 
the  exercise  type  and  the  event  number,  since  this  informa- 
tion determines  the  event  to  which  you  are  referring.  Upon 
entering  a  new  event  the  system  will  automatically  give  you 
an  event  number  based  on  the  year  in  which  it  is  scheduled. 
Once  the  system  knows  what  event  to  which  you  are  referring, 
you  may  either  add,  modify,  or  delete  information  from  that 
even  t . 

2 .  Form  Description: 

The  schedule  contains  six  blocks:  Exercise,  Brief, 
Users,  Weapon,  Target,  and  Comments.  These  blocks  are  the 
basic  subdivision  used  by  SQL*FORMS.  This  grouping  of 
information  allows  for  quicker  navigation.  Using  the  Next 
Block  <page  down)  and  Previous  Block  <page  up>  any  block  may 
be  accessed  quickly. 

The  exercise  data  block  is  the  first  block  and  contains 
three  pages  of  data.  The  first  page  contains  the  exercise, 
event  number  and  scheduled  start  and  stop  times  along  with 
other  general  event  information.  The  second  page  contains 
tracking  requirements,  and  message  information,  while  the 
third  contains  information  on  recovery  vehicles. 

The  next  block  is  the  Brief  block.  It  contains  infor — 
mation  on  briefs  associated  with  the  event.  This  block  is 
set  up  to  allow  multiple  briefs  to  be  entered  for  an  event. 
Entering  nothing  into  the  block  will  move  you  directly  to 
the  User  Block . 

The  User  block  contains  information  about  the  commands 
scheduled  to  use  the  range  during  this  event.  Many  users 
can  be  involved  in  a  single  event.  To  view  other  users,  the 
Next  Record  key  <down  arrow)  can  be  used  to  scroll  both  the 
user  and  the  weapons  associated  with  it.  Entering  a  blank 
in  the  command  field  will  move  you  to  the  Target  block, 
while  next  block  will  move  you  to  the  Weapon  block. 

The  Weapon  block  is  on  the  same  page  as  the  User  block. 
This  arrangement  allows  the  weapons  data  to  be  viewed  with 
their  respective  user.  This  block  allows  you  to  view  two 
weapons  at  a  time  and,  as  indicated  above,  Next  Record  <down 
arrow)  and  Previous  Record  <up  arrow)  can  be  use  to  scroll 
the  records. 
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The  Target  block,  located  on  page  four,  allows  entry  of 
data  pertaining  the  target  scheduled  for  an  event. 

The  last  block  is  the  Comments  block  which  contains 
notes  on  the  event.  Upon  completion  of  this  block,  all  data 
entered  is  automatically  stored  into  the  database. 

3 .    Add  Procedures: 

This  section  describes  how  new  data  is  entered  into  the 
system.  This  is  a  general  description  of  the  process  and 
should  be  used  in  conjunction  with  the  detailed  field  de- 
scriptions. Before  starting  to  enter  new  data,  you  should 
have  at  hand  all  of  the  information  you  are  going  to  enter, 
particularly  the  exercise,  user,  and  target  information. 

Step  1.    Start  at  the   top  of  the  form   (  If  not  at   top  of 

form,  select  Previous  Block  <page  up>  until  you  get  a  mes- 
sage saying  "top  of  form"  on  the  status  line).  Select 
Create  Record  <F9> ,  which  sets  up  the  form  to  enter  a  new 
record . 

Step  2.  Enter  your  exercise  type  and  the  last  two  digits 
of  the  year  in  which  the  event  will  occur.  This  allows  the 
system  to  calculate  the  proper  event  number. 

Step  3.  Enter  your  data,  field  by  field  as  described  in 
the  detailed  field  descriptions. 

Step  4.  Once  you  are  in  the  Brief  Block  enter  your  infor- 
mation regarding  the  first  brief.  After  entering  the  brie- 
fer, the  block  will  clear  and  the  cursor  repositions  to  the 
brief  title  field.  You  can  enter  another  brief  or,  if  fin- 
ished entering  briefs,  press  return.  You  will  now  be  at  the 
top  of  the  User  block.   Enter  your  user  data. 

Step  5.  After  entering  your  user  data,  you  are  presented 
with  the  Weapon  block.  Enter  the  data  for  the  first  weapon. 
Following  the  pinger  channel  entry,  the  cursor  will  reposi- 
tion under  the  first  weapon  entered.  Continue  entering  data 
for  all  weapons  scheduled.  Pressing  return  on  an  empty  "Type 
of  Weapon"  field  will  return  you  to  a  blank  User  block.  You 
have  the  option  of  entering  another  user  or  nothing.  If  you 
entered  all  your  users  then  enter  nothing  and  move  to  the 
target  block . 

Step  6.  Enter  your  target  data.  When  finished  you  will 
move  into  the  Comments  block.  Enter  your  comments,  pressing 
return  twice  when  finished.  All  data  entered  is  stored  and 
you  are    returned  again  to  the  first  screen. 
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4 .    Modify  Procedures: 


Modi  f y i 
retrieve  (s 
screen ,  then 
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you  can  not 
new  brief  or 
or  Next  Fie 
screen .  To 
User  block 
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Next  Record 
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ng  an  existing  entry  is  straightforward.  First, 
ee  Querying   the   Database)   the   event   to   the 

change  or  add  data  as  if  you  were  entering  data 

t  time.   The  exception  to  this  procedure  is  that 

change   exercise  or  event  numbers.    To  enter   a 

user  you  must  either   select  Create  Record<F9> 

Id  <enter>  until  a   blank  record  appears   on  the 

add  a  weapon  to  an  existing  command  go  to  the 
and  select   Next  Record  <down   arrow)  until   the 

name  appears.  Then  use  Next  Field  (enter)  to 
lank  weapon  line  and  enter  the  information.  To 
tional  target,  go  to  the  Target  block  and  select 

<enter>   or  Create  Record   <F9> ,  and   enter  the 

To  add  additional   comments  just  add   them  to 

comments.   Note   however,  blank  lines   are  not 

f  you  want  to   separate  comments,  use   some  key- 

1,  such  as   "*",   "-",  or  "="  on   a  line  to  sep- 
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Query  Database: 
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the  database  in  this  application 
s  except  the  Exercise  block  que- 
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response  to  a  query  will  be  those 

se  type  and  event  number  displayed 
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retrieve  all  events.  They  may  then 
selecting  Next  Record  (down  arrow) 

The  other  type   of  query  is 
which  you   retrieve  records   that 
criteria  (For  example,  exercise  ty 
also  done   from  the  Exercise  block 
and  enter   the  selection  criteria 
wish  to   query,  then  select  Execut 
would  be   to  query  all  data   relev 
cise.    The  procedure   would  be: 
enter  the  exercise  type  and  the  ev 
Execute   Query  <F2> .   This   would 
or  say   no   record  selected,   in  w 
another   query.   More   complex  que 
described  in  the  SQL*FORMS  Operato 


be  viewed  sequentially  by 

a  selected  query,  through 
satisfy  certain  selection 
pe  =  "Torpex").  This  is 
Select  Enter  Query  <F1> 
into  the  fields  that  you 
e  Query  <F2> .  One  example 
ant  to  a  particular  exer- 
(1)  Enter  Query  <F1>,  (2) 
ent  number,  and  (3)  select 
either  retrieve  the  record 
hich  case  you  can  enter 
ries  are  possible  and  are 
r's  guide  chapter  11. 


7. 


Detailed  Field  Descriptions 


This  section  provides   a  quick  reference 
and  shows  the  screen  layouts. 


on 


each    field 


Exercise  Block  (Page  l)i 


!                 INPUT  NEW  EVENT  DATA 

!        !  EXERCISE  TYPE!  EVENT  NUMBER:  ! 

1         I    EXERCISE  DESCRIPTION:             ! 

!                  EXERCISE  TINES: 

!   SCHEDULED  START:             SCHEDULED  FINISH: 

!     NOCS  MAN-UP:              MOCS  SHUT-DOWN:            \ 

!                 EXERCISE  PERSONNEL: 
!              PROJECT  ENGINEER} 

OPERATION  CONTROL: 

i             OPERATION  ANALYST: 

!               SAFETY  OFFICER: 

!  OPERATIONAL  AREA  A5SI6NED:           EXCLUSIVE  USE?: 

Fie  Ids : 

Exercise  Type:    Enter  the  type  of  exercise  to  be  scheduled 
List  Values   <F4>  can  be  used  to   review  standard  exer- 
cises. This  field  is  mandatory. 
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Event  Number:  In  this  field  the  only  input  allowed  are  the 
last  two  digits  of  the  year  in  which  the  exercise  will 
occur.  Once  this  data  is  entered,  the  proper  event 
number  is  automatically  generated.  This  field  is 
mandatory . 

Exercise  Description:  This  field  is  automatically  filled 
in  based  on  the  exercise,  but  may  be  changed  to  fit  the 
actual  exercise  needs. 

Schedule  Start:  Enter  the  schedule  start  time  in  standard 
military  date-time  group  format  DDHHMMZ  MONYY.  Where 
DD  is  the  day  of  the  month,  HHMM  is  military  time,  Z  is 
the  time  zone  (San  Diego  is  U  time) ,  MON  is  the  three 
letter  abbreviation  for  the  month,  and  YY  is  the  last 
two  digits  of  the  year.  Entering  the  wrong  format  will 
cause  an  error  message  to  be  displayed.  To  get  more 
information  on  the  error  Display  Error  <shift-F10>. 


Scheduled  Finish:   Thi< 
event .   I t  has  to 
above . 


is   the  scheduled  stop  time  for   the 
be  in  the  standard  format   described 


MOCS  Man-up:  This  is  the  time  that  the  MOCS  should  be 
manned  up.  The  default  is  one  hour  before  the  sched- 
uled start  time.  This  must  be  in  standard  format 
DDHHMMZ  MONYY. 

MOCS  shut-down:  This  is  the  time  scheduled  to  shut  down 
the  MOCS.  The  default  is  one  hour  after  scheduled 
finish.  This  is  also  entered  in  standard  format. 

Exercise  Personnel:  These  four  fields  are  used  to  indicate 
the  personnel  scheduled  for  the  event.  You  may  enter 
either  initials  or  up  to  10  characters  of  their  name. 

Operational  Area:  The  scheduled  operational  area  of  the 
event . 

Exclusive  Use:  This  Y/N  field  indicates  if  the  operational 
area  is  reserved  exclusively  for  the  exercise. 
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Exercise  Block  (Page  2): 

* — 


MISCELLANEOUS  EVENT  DATA 


EXERCISE  TYPE: 


EVENT  NUMBER: 


TRACKING  TYPE: 


EVENT  MESSAGES: 
6REEN  REQUIRED?:  _      BREEN  SENT?: 
SUBMARINE  RELAXATION  HESSA6E  REQUIRED?: 


AIR  SPACE  RESTRICTIONS: 

COMMUNICATIONS: 


Fie  Ids : 

Exercise,  Event:  These  fields  are  are  replicated  from  the 
first  page  and  cannot  be  entered. 

Tracking  Type:  The  type  of  tracking  required  for  the 
event.  Enter  E  for  EATS  tracking,  I  for  in-water  or 
B  for  both. 

Green  Required:  Is  a  rainform  green  message  required. 
Enter  either  Y  or  N.  If  one  is  not  required,  the  fol- 
lowing Green  Sent  field  is  skipped. 

Green  Sent:  This  field  defaults  to  N  and  should  be  changed 
to  Y  when  the  required  rainform  green  message  is  sent. 

Submarine  Relaxation:  This  is  used  to  indicate  if  a  sub- 
marine relaxation  message  is  required,  either  Y  or  N. 

Air  Space  Restrictions:  This  field  states  the  altitude 
limits  for  aircraft  involved  in  the  event.  The  heights 
are  in  hundreds  of  feet  with  the  low  altitude  first. 
For  instance  if  the  allowable  altitude  was  0  to  5000  ft 
the  entry  would  be  00-50. 

Communications:  This  is  the  primary  frequency  for  com- 
munication during  the  exercise,  usually  UHF . 
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Exercise  Block  (Page  3): 

+ 

i 
i 

♦--+-- 

i 
i 

+-- 


EVENT  SUPPORT  VEHICLES 
EXERCISE  TYPE:        EVENT  NUMBER: 


TAR6ET  SUPPORT  VEHICLES: 

PRIMARY  TAR6ET  RECOVERY:  

SECONDARY  TAR6ET  RECOVERY: 


■♦-- + 

i 
i 

-+ 


WEAPON  SUPPORT  VEHICLES: 

PRIHARY  WEAPON  RECOVERY:  

SECONDARY  WEAPON  RECOVERY:  

WEAPON  HAULBACK:  


Fields: 

Exercise,  Event:  These  fields  are  replicated  from  the  first 
page  and  cannot  be  entered. 

Recovery  Vehicles:  These  five  fields  are  for  listing  the 
primary  and  secondary  vehicles  scheduled  to  provide 
support  to  the  event.  In  each  field  enter  the  name  of 
the  command  that  will  provide  that  support.  List 
Values  <F4>  may  be  used  to  list  commonly  used  commands. 
After  weapon  haulback  is  entered  you  will  move  to  the 
Brief  Block. 
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Brief  Block  (Page  4)i 


INPUT  EXERCISE  BRIEF  DATA 

EXERCISE  TYPEi  EVENT  NUMBER:  

TITLE  OF  BRIEFi 

TIHEi 

LOCATION: 

BRIEFER! 

Fields : 

Exercise,  Event:  These  fields  are  replicated  from  the  first 
page  and  cannot  be  entered. 

Title  of  Brief:  Enter  the  title  of  the  brief.  Leaving 
thi-s  field  blank  will  move  yow  directly  to  the  M^er 
Block . 

Time:  Enter  the  scheduled  time  of  the  brief  in  standard 
date-time  group  format  DDHHMMZ  MONYY.  See  Exercise 
block  scheduled  start  field  for  details  of  the  date- 
time  format. 


Location : 


Enter  the  location  where  the  brief  will  be  held. 


Briefer:  Enter  the  Name  of  the  person  who  will  give  the 
brief.  After  entering  this  field  you  will  move  back  to 
the  Title  of  Brief  field,  allowing  you  to  enter  another 
brief . 
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User  Block  (Page  5): 


ENTER  USER  DATA 

I  EXERCISE  TYPEi  EVENT  N 

UMBER i 

1        1 
1        1 

NAME  OF  COMMAND! 

NUMBER  OF  UNITSi  __ 

PINSER  CHANNEL! 

(IF  SUBMARINE) 

TRANSPONDER-EQUIPPED?! 

(IF  AIR  OR  SURFACE) 

TYPE  OF  WEAPON       NUMBER 

PINSER 

(HK)          SCHEDULED 

CHANNEL 

Fields : 


Exercise,   Event:      These  fields  are    replicated 
first  page  and  cannot  be  entered. 


from  the 


Name  of   Command:     Enter   the  name   of  the 
command  designations  ( ie  VP-44,  SSN-680 ) 
this   field   blank   the  system   assumes 
entered  all   the  commands  for  this  event 
to  the  Target  Block. 


command,  using 

If  you  leave 

that   you  have 

and  moves  you 


Number  of  Units:  This  field  is  entered  only  if  the  command 
is  an  aircraft  squadron.  Enter  the  number  of  aircraft 
from  this  command  that  will  participate  in  the  event. 

Pinger  Channel:  This  field  is  entered  only  if  the  command 
is  a  submarine.  Enter  the  pinger  channel  to  be  in- 
stalled on  the  sub.  From  this  field  you  move  directly 
to  the  Weapon  block  on  the  same  page. 

Transponder  Equipped:  This  applies  only  to  ships  and 
aircraft.  Enter  the  type  of  transponder  to  be  in- 
stalled. After  entering  this  field  you  move  to  the 
Weapon  block  on  the  same  page. 
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Weapon  Block: 

Fiel ds : 

Type  of  Weapon:   Enter  the  type  of  weapon  scheduled  for  this 

command.    Leaving  this  field  blank  will   move  you  back 

to   the   user   block   allowing   you   to   enter  another 
command . 


Number  Scheduled: 
scheduled . 


Enter  the  number  of  weapons  of  this  type 


Pinger  channel:  Enter  the  pinger  channels  to  be  used  by 
the  weapons.  If  four  weapons  are  scheduled,  two  with  A 
pingers  and  two  with  B  pingers,  then  enter  2A2B.  After 
entering  this  field  you  will  move  back  to  Type  of 
Weapon  field  allowing  another  type  of  weapon  to  be 
scheduled  for  this  user. 


Targit  Block  (Pagi  6)1 


ENTER  TARGET  DATA 

EXERCISE  TYPE:  EVENT  NUMBER:  

TAR6ET  DESIGNATION:  6E0HETRY  CODE: 

PROPER  ACOUSTICS?:        PINGER  CHANNEL: 


TARGET  LAUNCH  VEHICLE: 


Fields: 


Exercise,  Event: 


These  fields  Are    replicated  from  page  1. 


Target  Designation:  This  field  contains  the  designation  of 
the  target.  If  the  target  is  a  ship  or  submarine  the 
designation  is  just  its  command.  If  it  is  a  mechanical 
target,  enter  its   MK  number.   If  the  target   is  a  ship 


or    submarine 


pi icable , 
block . 

Geometry  code: 
target . 


and 


the  remainder   if  the  block   is  not   ap- 
you  will   move  directly   to  the   Comment 


Enter   the  geometry   programmed  into   the 
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Proper  Acoustics:  Verify  that  the  target  has  the  proper 
acoustics,  either  Y  or  N. 

Pinger  channel:  Enter  the  pinger  channel  to  be  used  by  the 
target . 

Target  Launch  Vehicle:  Enter  the  command  that  will  launch 
the  target.  After  entering  this  field  you  will  move  to 
the  Comments  Block. 


Coiimti  Block  (Pigi  7)i 


COMMENTS 


COMMENTS 


Fields: 


Comments:  This  field  allows  you  to  enter  any  comments 
pertaining  to  the  event.  You  may  use  as  many  lines  as 
necessary.  To  move  to  the  Next  Line  select  enter  <cr> . 
To  move  to  the  Next  Block  select  enter  <cr>  twice.  You 
will  then  be  at  the  top  of  the  form  in 
b 1 ock . 


the  Exercise 
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PART  II   RESULTS 

1  .     In troduc tion  : 

This  application  stores  the  data  recorded  during  the 
event  so  that  it  can  be  reviewed  and  analyzed  later.  It 
also  allows  the  user  to  query  and  generate  reports  on  the 
stored  data.  As  with  the  schedule  application,  it  was 
designed  to  minimize  the  effort  required  for  data  entry. 
The  same  <enter>  key  will  move  you  through  the  entire  form. 
Before  an  event  can  be  entered  it  must  first  exist  in  the 
Schedule  application,  ensuring  that  data  can  pass  between 
the  two  applications.  This  application  is  much  larger  that 
Schedule  and  has  more  blocks,  but  should  be  no  more  complex 
to  operate. 

2 .    Form  Description: 

The  form  contains  13  blocks  on  nine  screen  pages.  The 
blocks  are  Result,  Cancel,  Launch/Recovery,  User,  Scheduled 
Weapons,  Attack,  Attack  Comments,  Weapon,  Target,  Unclas- 
sified Comments,  Classified  Comments,  and  Lost. 

The  Result  block  is  the  first  and  master  block.  It 
contains  the  exercise  type  and  event  number,  along  with  the 
oparea,  comex,  finex  and  weather  information.  This  is  the 
only  block  from  which  you  can  query  multiple  events. 

The  next  two  blocks,  Canceled  and  Launch/Recovery,  are 
also  on  page  one.  Canceled  is  for  entering  reasons  why  part 
or  all  of  an  event  was  canceled.  The  Launch  and  Recovery 
block  records  whether  or  not  a  scheduled  recovery  vehicle 
was  used.  Both  of  these  blocks  are  multi-record  blocks, 
showing  up  to  three  cancellations  and  four  recovery  vehicles 
at  once.  As  in  all  other  multi-record  blocks  entering 
nothing  moves  you  to  the  next  block. 

On  page  two  are  the  User  and  Scheduled  Weapon  blocks. 
The  User  block  records  the  actual  platform  that  was  on  the 
range.  From  this  block,  you  move  into  the  Scheduled  Weapon 
block  which  is  a  multi-record  block. 

The  Attack  block  on  page  three  is  one  of  the  most 
important  because  it  records  all  the  attack  data  for  the 
command  in  the  User  block.  This  block  covers  two  pages  and 
leads  directly  into  Attack  Comments.  These  comments  go 
directly  with  the  attack  described  above  it. 

Moving  to  page  five,  we  start  to  see  the  complex  navi- 
gation controls  of  this  application.  The  path  so  far  has 
moved  directly  through  the  form.  Attacks  can  involve  actual 
or  simulated  weapons.  If  the  attack  was  simulated  you  will 
return  to  the  Attack  block,  allowing  you  to  enter  another 
attack.  Otherwise  you  may  enter  Weapon  data,  which,  upon 
completion,  will  also  bring  you  back  to  the  Attack  block. 
If  there  are  no  more  attacks  conducted  by  this  platform  you 
will  return  to  the  User   block  were  another  platform  may   be 

126 


entered.  If  all  users  for  an  event  have  been  entered  you 
move  on  to  the  Target  block. 

The  Target  block  covers  information  on  the  target. 
Once  this  is  entered  you  will  move  to  the  event  Comment 
blocks.  The  first  is  for  general  comments  on  the  exercise, 
while  the  second  is  for  any  comments  that  are    classified. 

The  last  block  is  the  Lost  block  for  recording  informa- 
tion on  lost  weapons  or  targets.  The  only  way  to  get  to 
this  block  is  for  a  loss  to  be  recorded  in  either  the  Weapon 
or  Target  blocks.  Upon  leaving  this  block,  you  will  either 
return  to  the  Attack  block  (if  the  item  lost  was  a  weapon), 
or  to  the  Unclassified  Comments  block  (if  the  item  lost  was 
a  target ) . 


3  .    Add  Procedures: 

This  section  explains  how  new  data  is  entered  into  the 
system.  This  is  a  general  description  of  the  process  and 
should  be  used  in  conjunction  with  the  detailed  field  de- 
scriptions provided  below.  Before  entering  new  data  you 
should  have  the  exercise  summary  at  hand. 

Step  1.  Start  at  the  top  of  the  form  (If  not  at  top  of 
form,  select  Previous  Block  <page  up>  until  you  get  a  mes- 
sage saying  "top  of  form"  on  the  status  line).  Select 
Create  Record  <F9> ,  which  sets  up  the  form  to  enter  a  new 
record . 

Step  2.  Enter  your  exercise  type.  Next  enter  the  event 
number.  Once  these  items  a.re  entered  you  can  select  Dupli- 
cate Record  <F7> ,  which  will  copy  pertinent  data  from  the 
schedule  into  the  Results  form  (this  may  take  10  to  15 
seconds  to  complete).  You  can  now  edit  or  accept  the  values 
copied  over  from  the  schedule. 

Step  3.  Continue  to  enter  data  until  you  get  to  the  Can- 
celed block.  Here,  if  no  cancellation  occurred,  leave  blank 
and  move  to  Launch  and  Recovery  assets. 

Step  4.  You  need  to  edit  the  Launch  and  Recovery  values 
copied  from  the  schedule.  If  the  platform  was  not  avail- 
able, delete  it  using  Delete  Record  <shift-F5>.  The  side 
numbers  have  to  be  changed  to  match  the  actual  side  number. 
When  finished,  select  Next  Field  <enter>  until  you  move  to 
the  nex  t  block . 

Step  5.  You  are  now  in  the  User  block.  Enter  your  user 
data,  moving  automatically  into  Scheduled  Weapons.  When  you 
finish  entering  the  scheduled  weapons  you  will  move  to  the 
Attack  block. 
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Step  6.  Enter  your  attack  data  and  attack  comments.  Once 
this  is  complete  you  will  move  to  the  Weapon  block.  If  no 
weapon  was  fired  leave  blank,  otherwise  enter  the  informa- 
tion (if  a  weapon  was  lost  see  step  8).  In  either  case  you 
will  return  to  a  blank  Attack  block.  You  may  enter  another 
attack  for  the  displayed  platform,  or  leave  blank.  Leaving 
the  field  blank  returns  you  to  the  User  block.  Again  you 
can  enter  another  user  or  leave  blank.  Leaving  the  field 
blank  takes  you  to  the  Target  block. 

Step  7.  In  Target  block  enter  the  appropriate  data  (if  the 
target  was  lost  see  step  8  ).  When  target  entry  is  complete 
you  will  move  through  the  Comment  blocks  and  then  back  to 
the  first  page  of  the  application  to  enter  additional  exer- 
cise results. 

Step  8.  If  you  indicated  that  a  weapon  or  target  is  not 
recovered  you  will  move  automatically  to  the  Lost  block. 
Here  you  enter  data  about  the  loss.  Upon  completing  the 
block  you  will  exit  to  the  Attack  block  (if  the  item  lost 
was  a  weapon),  or  to  the  Unclassified  Comments  block  (if  the 
item  lost  was  a  target). 

After  entering  an  event  the  data  will  be  saved  and  you  will 
return  to  the  top  of  the  form.  You  can  repeat  the  process 
and  enter  another  event  or  perform  another  operation. 


4 .  Modify  Procedures: 

Modifying  an  existing  entry  is  straightforward.  First, 
retrieve  (see  Querying  the  Database)  the  event  to  the 
screen,  then  change  or  add  data  as  if  you  were  entering  data 
for  the  first  time.  The  exception  to  this  procedure  is  that 
you  may  not  change  exercise  type  or  event  number.  To  enter 
a  new  User  or  Attack  you  must  select  Create  Record  <F9>  in 
that  block.  To  add  a  Cancellation  or  a  Support  vehicle,  you 
must  go  to  the  desired  block  and  select  Next  Record  <down 
arrow)  until  a  blank  line  appears,  then  enter  the  informa- 
tion. To  add  an  additional  target,  go  to  the  Target  block 
and  select  Next  Record  <down  arrow)  or  Create  Record  <F9>, 
then  enter  the  information.  To  add  additional  Comments, 
just  add  then  to  the  previous  comments.  Note,  however,  that 
blank  lines  are  not  allowed.  If  you  want  to  separate  com- 
ments use  keyboard  symbols  such  as  "*",  "-" ,  or  "="  to 
separate  them. 

5 .  Delete  Procedures: 

Delete  works  on  many  levels:  you  can  delete  an  entire 
event  or  any  of  its  associated  objects.  You  can  only  delete 
an  entire  event,  however,  if   it  has  no  associated  Users   or 
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Targets.  This  prevents  inadvertent  deletion  of  records. 
This  same  procedure  applies  to  User.  No  user  can  be  deleted 
if  an  Attack  is  associated  with  it. 

To  delete  an  entire  event  perform  the  following  steps: 
1)  Delete  all  Attacks  associated  with  the  Users  of  the  event 
(this  automatically  deletes  all  Attack  Comments);  (2)  Delete 
all  Users  of  the  event  (this  automatically  deletes  all 
Weapons  assigned  to  the  Users);  (3)  Delete  Target(s)  as- 
sociated with  the  event;  and  (4)  Enter  the  Result  block  and 
select  Delete  Record  <shift-F5>,  which  automatically  deletes 
all  Comments,  Cancellations  and  Support,  along  with  the 
event  i tsel f . 

If  there  are  no  Users  and  Targets  associated  with  an 
event  to  be  deleted,  go  directly  to  step  (4). 

All  other  blocks  can  be  deleted  individually  as  shown 
in  the  SQL*FORMS  manual. 


6 .    Query  Database: 

The  ability  to  guery  the  database  in  this  application 
is  limited.  In  all  blocks  except  the  Result  block,  gueries 
are  constrained  by  the  exercise  type  and  event  number  dis- 
played. For  example,  if  you  execute  a  guery  in  the  Attack 
block,  the  response  to  the  guery  will  pertain  to  the  par- 
ticular exercise  type  and  event  number  displayed  at  the  top 
of  the  Attack  block.  Even  with  this  limitation,  full  gueries 
may  be  performed. 

The  easiest  guery  to  perform  is  a  general  query.  This 
retrieves  all  records.  To  perform  this  query,  enter  the 
Result  block  and  select  Execute  Query  <F2> .  This  will 
retrieve  all  events  which  may  then  be  viewed  sequential ly  by 
selecting  Next  Record  <down  arrow). 

The  other  type  of  query  is  a  selected  query,  through 
which  you  retrieve  records  that  satisfy  selected  criteria 
(For  example,  exercise  type  =  "Torpex").  This  query  is  also 
executed  from  the  Result  block.  The  general  query  procedure 
is  as  follows:  1)  Select  Enter  Query  <F1>;  2)  Enter  selec- 
tion criteria  into  the  fields  you  wish  to  query;  and  3) 
Select  Execute  Query  <F2> .  One  example  would  be  to  find  a 
particular  exercise.  After  entering  the  Result  block,  the 
procedure  would  be:  1)  Enter  Query  <F1>;  2)  Enter  the  exer- 
cise type  and  event  number;  and  3)  Select  Execute  Query 
<F2> .  This  will  either  retrieve  the  desired  record  or  say 
"no  record  selected",  in  which  case,  you  can  enter  another 
query.  More  complex  queries  are  possible  and  are  described 
in  the  SQL*FORMS  Operator's  guide  chapter  11. 
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Result  Block  (Pige  1): 
♦ 


EXERCISE  S  U N H A  R  Y 

EXERCISE      EVENT       EXERCISE  DESCRIPTION 

OPAREA 

COHEX                  VISIBILITY 

FINEX                  SEA  STATE 

REASON  CANCELED         HOURS   TIME  OF 

LOST   CANCELLATION 

LAUNCH/RECOVERY  ASSETS 
PLATFORM    SIDE  NUMBER   USED 

Special  Keys: 

Duplicate  Record  <F7>:  This  key  copies  information  from 
the  Schedule  to  the  Results  application.  After  enter- 
ing the  exercise  type  and  event  number,  press  this  key 
to  copy  the  oparea,  scheduled  comex  and  finex  into  the 
appropriate  fields.  It  will  also  list  all  the  recovery 
vehicles  in  the  launch/recovery  block. 


Fields : 

Exercise:  Enter  the  type  of  exercise.  (Standard  exercise 
types  are  available  by  selecting  List  of  Values  <F4>) 
This  field  is  mandatory,  and  must  exist  in  the 
sc  hedu le . 

Event:  Enter  the  event  number.  This  field  is  also  man- 
datory, and  the  event  must  be  in  the  schedule. 

Exercise  Description:  This  field  is  automatically  filled 
in  and  cannot  be  edited. 


Oparea:    Enter  the  operational  area    in  which  the  event  took 
p 1  ace . 
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Comex :  Enter  the  date  and  time  of  the  comex  in  standard 
military  date  time  group  format  DDHHMMZ  MONYY.  Where  DD  is 
the  day  of  the  month,  HHMM  is  military  time,  Z  is  the  time 
zone  (San  Diego  is  time  zone  U),  MON  is  the  three  letter 
month  abbreviation  and  YY  is  the  last  two  digits  of  the 
year.  If  this  format  is  not  used  an  error  message  will 
appear;  select  Display  Error  <shift-F10>  to  get  a 
description  of  the  error. 

Finex :     Enter   the  finex   time  of   the  event   in  the   same 
format  as  above. 

Visibility:    Enter  the   visibility  in  nautical  miles.  Enter 
99  to  indicate  unlimited  visibility. 

Sea   state:     Enter  the   single  digit  representing   the  sea 
state. 


Canceled  Block: 

Fields: 

Reason  Canceled:  This  is  the  reason  for  which  part  or  all 
of  the  event  was  canceled.  There  Are  six  valid  en- 
tries: asset  availability,  fouled  range,  instrumenta- 
tion, weather,  no  air  tracks,  and  no  show.  These 
values  are  available  using  List  of  Values  <F4>.  Making 
no  entry  moves  the  cursor  to  the  Launch/Recovery  Block. 

Hours  lost:  This  field  records  the  length  of  the  cancella- 
tion period.  This  data  is  recorded  in  hours  and  tenths 
of  hours. 

Time  of  Cancellation:  Enter  the  time  at  which  the  cancel- 
lation started.  The  format  is  the  standard  date-time 
group  format  of  DDHHMMZ  MONYY.  See  comex  in  the  result 
block  for  more  details.  Once  this  is  entered  you  will 
move  to  enter  the  next  reason  canceled. 


Launch/Recovery  Block: 

Fields : 

Platform:  Enter  the  command  name  of  the  support  vehicle. 
If  Duplicate  Record  was  selected  in  the  Result  block 
the  command  name  will  be  filled  in  from  the  schedule. 
If  the  schedule  information  was  incorrect,  select 
Delete  Record  <shift-F5>  to  delete  the  line.  If  this 
field  is  left  blank  you  will  move  to  the  User  Block. 
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Side  number:  Enter  the  side  number  of  the  vehicle.  The 
values  copied  from  the  schedule  have  the  letters  A,  B, 
C,  and  D.  Insert  the  correct  side  number. 

Used:  A  Y/N  entry  indicating  whether  or  not  the  vehicle 
was  actually  used  to  support  the  event.  If  it  stayed  in 
port  or  on  the  ground  the  answer  is  N.  If  the  vehicle 
was  broken  or  not  available  then  it  should  not  be 
listed.  After  entering  this  field  you  will  move  to  the 
next  platform  in  the  list. 


User  Block  (Page  2)t 

USER  DATA 


!  EXERCISE 

COHHAND  DESIGNATION 

SIDE  NUMBER 

SHOWED  FOR  EXERCISE 

TRACK  QUALITY  

S0N06U0Y  USAGE)  LOFAR 

DIFAR 

DICAS  _ 

VLAD   _ 

WEAPON  TYPE    NUMBER 

REASON 

SCHEDULED 

NOT  DROPPED 



- 

Fields: 

Exercise:  This  field  is  replicated  from  the  exercise  type 
and  event  number  fields  of  the  Result  block  and  cannot 
be  en  tered . 

Command  Designation:  The  name  of  the  command  using  the 
range.  The  name  is  the  standard  Navy  designation  for 
the  command  ( ie  v"P-44  or  SSN-680).  For  consistency 
include  the  hyphen.  If  this  field  is  left  blank,  the 
system  assumes  you  have  entered  all  the  commands  in- 
volved in  the  event  and  you  move  to  the  Target  Block. 
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Side  number:  This  field  is  only  entered  if  the  command  was 
an  aircraft  squadron.  Enter  the  side  number  of  the 
actual  aircraft  that  used  the  range.  If  a  squadron  was 
scheduled  for  two  aircraft  and  one  did  not  show  enter  a 
NS  for  no  show. 

Showed  for  exercise:  A  Y/N  entry  indicating  whether  or  not 
a  scheduled  user  showed  up  for  the  event. 

Track  quality:  Enter  the  quality  of  the  track  observed  by 
the  range,  from  0  (no  track)  to  100  (a  perfect  track). 
After  entering  this  field  aircraft  move  to  the  sonobuoy 
field;  all  others  go  directly  to  Scheduled  Weapons. 

Sonobuoy  Usage:    These  four  fields  record  how  many  buoys  an 

aircraft  uses.   Enter  the  number  of  buoys  used  for  each 

type.    When  exiting  the  last   field,  you  will  move  to 
the  Weapon  block. 


Weapon  Block: 

Fie  Ids : 


Weapon  type:  Enter  the  type  of  weapon  scheduled,  either 
MK-46  or  MK-48 .  The  system  will  search  the  Schedule 
and   copy  the   number   scheduled   into  the   appropriate 


field.   If  this  field 
the  Attack  block. 


is  left  blank,  you  will   move  to 


Number  scheduled:  This  field  records  how  may  weapons  were 
originally  scheduled.  The  total  number  of  weapon  type 
scheduled  for  a  command  is  copied  into  this  field.  For 
aircraft  squadrons,  this  number  needs  to  be  verified 
because  the  weapons  may  have  been  divided  equally  among 
all  pi atf orms . 

Reason  Not  Dropped:  A  code  indicating  why  all  scheduled 
weapons  were  not  dropped.  The  codes  a.re:  A)  platform 
problems,  B)  torpedo  problems,  C)  weather,  D)  inade- 
quate recovery  assets,  E)  time  constraints,  F)  fouled 
range,  G)  inadequate  TMA,  H)  pinger  problem,  and  I) 
other.  After  entering  this  data  you  will  be  able  to 
enter  the  next  weapon  scheduled  for  this  platform. 
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Attack  Block  (Pige  3)i 


ATTACK 

DATA 

!  EXERCISE 



COMMAND 

SIDE  NUMBER 

TOF 

START  ATTACK  RUN 

TAR6ET  DATA 

COURSE 

BEARING 

RAN6E 

SPEED 

DEPTH 

MANEUVER i 
TIME 
COURSE 
SPEED 


SOLUTION  DATA 

COURSE  __ 

BEARIN6  

RANGE  

SPEED  __ 

DOPPLER 


FIRING  UNIT  DATA 

COURSE  __ 
SPEED  _ 
ALTITUDE 


Fields; 

Exercise:   Replication  of  exercise  type  and  event  number. 

Command:    The  command  that  conducted  the  attack. 

Side  number:  The  side  number  of  the  platform  that  per- 
formed the  attack  (if  applicable). 

TOF:  Time  of  Fire.  The  time  that  the  weapon  was  launched. 
This  identifies  the  attack.  The  time  must  be  entered 
in  standard  military  date-time  group  format  DDHHMMZ  - 
MONYY  .  See  Result  block  comex  for  more  information  on 
date-time  format. 

Start  Attack  Run:  Enter  the  time  at  which  the  platform 
starts  searching  for  the  target.  This  also  has  to  be 
entered  in  standard  date-time  group  format  DDHHMM  MON- 
YY. 

Target  Course:  Enter  the  course  of  the  target  at  TOF 
[recorded  in  degrees  true  (0-359)]. 

Target  Bearing:  Enter  the  true  bearing  from  the  platform 
to  the  target  at  TOF  (0-359). 

Target  Range:  Enter  range  from  platform  to  target  at  TOF 
in  yards . 
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Target  Speed:    Enter  the  speed  of  target  at  TOF  in  kts. 

Target  Depth:  Enter  the  depth  of  the  target  at  TOF  in 
feet. 

Maneuver  time:  The  time  in  minutes  after  TOF  at  which  the 
target  maneuvered.  The  time  is  recorded  in  minutes  and 
tenths  of  a  minute.  Enter  0  if  no  maneuver  after  TOF. 
Enter  0.1  if  maneuver  occurred  at  TOF.  If  0  is  entered 
the  maneuver  course  and  speed  are  skipped. 

Maneuver  course:  The  new  course  after  the  maneuver  [recor- 
ded in  degrees  true  (0-359)]. 

Maneuver  speed:  The  new  speed  of  the  target  in  kts  after 
the  maneuver. 

Solution  Course:  The  firing  solution  course  [measured  in 
degrees  true  (0-359)]. 

Solution  Bearing:    The  firing  solution  bearing  (0-359). 

Solution  Range:    The  firing  solution  range  in  yards. 

Solution  Speed:    The  firing  solution  speed  in  kts. 

Doppler:  A  code  entered  to  describe  the  amount  of  target 
doppler  the  firing  craft  was  reading.  The  codes  are: 
1)  doppler  >  +5  kts,  2)  doppler  between  +2.5  and  +5 
kts,  3)  doppler  between  -2.5  and  +2.5  kts,  4)  doppler 
between  -2.5  and  -5  kts,  5)  doppler  <  -5kts. 

Firing  Unit  Course:  Course  of  platform  at  TOF  [measured  in 
degrees  true]. 

Firing  Unit  Speed:    Speed  of  platform  at  TOF. 

Firing  unit  Altitude:  Altitude  of  aircraft  at  TOF.  This 
field  is  skipped  for  ships.  After  entry  you  will  move 
to  the  next  page  and  continue  entering  attack  informa- 
tion . 
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Attack  Block  (Pige  4)i 


ATTACK   DATA 

EXERCISE         UNIT      SIDE  NUMBER 

TOF 

FIRING  DATA 

CONTACT  TYPE 
ATTACK  NODE 
SONAR  SETTIN6 
DELIVERY  NODE 
SEARCH  DEPTH 


RESULTS 

ACQUIRED 

ATTACK  EVAL 

PH 

SPLASH  BEARIN6 

SPLASH  RANGE 


ATTACK  COMMENTS: 


Fields ; 

Exercise,  Unit,  side  number,  TOF:  These  fields  are  not 
entered;  replicating  earlier  recorded  data. 

Contact  Type:  Enter  the  sensors  used  to  develop  the  firing 
solution.  There  are  13  legal  values  which  can  be 
viewed  using  List  Values  <F4>. 

Attack  Mode:  Enter  how  the  torpedo  was  programmed  to 
perform  its  attack  (either  circle  or  snake). 

Sonar  Setting:  Enter  the  type  of  sonar  the  torpedo  used. 
There  are  four  settings  available  and  may  be  viewed 
using  List  Values  <F4> . 

Deliver  Mode:  Enter  how  the  weapon  was  launched.  There  are 
six  different  delivery  modes  which  may  be  viewed  using 
List  Values  <F4>. 

Search  Depth:  The  depth  at  which  the  weapon  starts  its 
search,  in  feet. 

Acguired:  How  many  times  did  the  weapon  acguire  the  tar- 
get. If  it  did  not  acguire  enter  0,  If  it  acquired  the 
target  more  than  nine  times  enter  9. 

Attack  Eval:  Evaluation  of  the  attack.  There  are  five 
legal  values,  HIT,  MISS,  PROB  HIT,  PR0B,MISS,  UNKNOWN. 
These  values  are    also  available  using  List  Values  <F4> . 
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If  the  platform  that  launched  the  attack  was  not  an 
aircraft  you  will  automatically  skip  to  Attack  Comments 
Block. 

PH:  Enter  the  decimal  value  of  the  Probability  of  Hit 
(0.00  to  1 .00) . 

Splash  Bearing:  The  relative  bearing  from  the  target  to 
the  splash  point  (0-359). 

Splash  Range:  Range  from  target  to  splash  point,  in  yards. 
After  entering  this  field  you  will  move  to  Attack 
Comments  Block. 


Attack  Comments  Block: 

Fields: 

Comments:  This  field  allows  you  to  enter  comments  that 
pertain  to  the  specific  attack  shown  at  the  top  of  the 
screen.  Select  return  at  the  end  of  each  line  to  move 
to  the  next  line.  Selecting  return  twice  will  move  you 
to  the  Weapon  Block. 

Ntipon  Block  (Pigi  9)i 

WEAPON   DATA 
+ - + 

!  EXERCISE UNIT  SIDE  NUMBER TOF  I 

+ - + 

HK        MOD        SERIAL  


TRACK  QUALITY  _      TORPEDO  PERFORMANCE 
WEAPON  RECOVERED (Y,N) 

SEARCH  TIME     RECOVER  VEHICLE 

TIME  TO  RECOVER         BRIN6  BACK  VEHICLE 


Fie  Ids : 

Exercise,   Unit,  Side  Number,   TOF:     These  fields  are    not 
entered,  but  are    replicated  from  earlier  data. 
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MK:  Enter  the  MK  of  the  weapon,  enter  MK-48,  MK-46  or  any 
other  weapon  used.  If  no  weapon  was  launched  as  in  a 
simulated  attack,  leave  blank  and  you  will  return  to 
the  attack  block  to  enter  another  attack. 

MOD:    Enter  the  mod  of  the  weapon. 

Serial:  Enter  the  serial  number  of  the  weapon  (up  to  seven 
characters  long). 

Track  Quality:  Enter  the  quality  of  the  weapon  track  from 
0  to  100. 

Torpedo  performance:  Enter  the  performance  of  the  weapon. 
There  are  six  legal  values  which  may  be  selected  by 
using  List  of  Values  <F4>. 

Weapon  Recovered:    This   field  indicates  if  the  weapon  was 

recovered  or   not.     If   N  is   entered,   you  will  move 

directly  to  the  Lost  block.   If  Y  is  entered,  you  will 
continue  entering  data  in  this  block. 

Search  Time:  Enter  into  this  field  the  number  of  seconds 
that  the  weapon  was  in  the  search  mode. 

Recover  vehicle:  The  vehicle  that  picked  up  the  weapon 
(i.e.,  TWR-789  or    HC-1  345). 

Time  to  Recover:  Enter  the  length  of  time  between  when  the 
weapon  stopped  running  and  when  it  was  retrieved. 
Measured  in  minutes. 

Bring  Back  Vehicle:  The  vehicle  that  returned  the  weapon 
to  San  Diego.  After  entering  this  field  you  will  move 
back  to  the  attack  block  to  allow  entry  of  another 
attack  by  this  platform. 
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Target  Block  (Pige  6)1 


TARGET       DATA 


EXERCISE 


TARGET  DESIGNATION 
LAUNCH  TIHE 
PERFORHANCE 
SOUND  LEVEL 
RECOVERED(Y.N) 


HOD 


SERIAL  NUMBER 
TRACK  QUALITY 
GEOMETRY 
FREQUENCY  BAND 
RECOVERY  VEHICLE 


Fields: 

Exercise:  This  field  is  not  entered,  but  replicates  exer- 
cise type  and  event  number. 

Target  Designation:  If  the  target  is  a  ship  or  submarine, 
enter  its  command  name.  For  a  mechanical  target  enter 
the  MK.  If  a  ship  or  submarine  is  entered  the  remain- 
der of  the  block  is  not  applicable,  and  you  move  to 
the  Comments  blocks. 

Mod:    Enter  the  mod  of  the  target. 

Serial  Number:    Enter  the  serial  number  of  the  target. 

Launch  time:  Indicate   the  target  launch  time  in   standard 

date-time  group  format  DDHHMMZ   MONYY .   See   the  Comex 

field   in  the  Results  block  for  more  information  on  the 

date-time  format. 

Track  quality:  Enter  the  quality  of  the  target  track 
during  the  event  (0  -100). 

Performance:  Enter  the  target  performance.  There  are  six 
legal  values  which  may  be  viewed  by  selecting  List 
Values  <F4>. 

Geometry:    Enter  the  geometry  that  was  used  by  the  target. 

Sound  Level:     Enter  the   average  sound  level   generated  by 
the  target  (measured  in  DB ) . 
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Frequency  Band:  Enter  the  type  of  sound  generated  by  the 
target.  The  two  legal  values  are  NB  for  narrow  band 
and  BB  for  broad  band. 

Recovered:  This  is  a  Y/N  field  indicating  if  the  target 
was  recovered.  If  it  was  not  recovered,  you  will  move 
to  the  Lost  block. 

Recovery  Vehicle:  The  vehicle  that  recovered  the  target. 
After  entering  this  field  you  will  move  to  the  Unclas- 
sified Comments  block. 


Unclmifitd  Comnti  Block  (Pigi  7)i 

UNCLASSIFIED    COMMENTS 
+ 

!    EXERCISE 

+ 

COMMENTS 


Fields: 

Comments:  Enter  general  comments  about  the  event.  The 
comments  may  be  as  many  lines  as  needed.  Use  <Enter> 
to  move  to  the  next  line.  Pressing  <Enter>  twice  will 
move  you  to  the  Classified  Comments  block. 


Classified  Comments  Block  (Page  8): 

This  block  is  identical  to  Unclassified  Comments  but  is 
for  classified  comments.  Selecting  <Enter>  twice  will 
move  you  back  to  the  top  of  the  form  (Result  block). 
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Loit  Block  (Pigt  9)i 

LOST      TARGETS      AND      WEAPONS 
+— 

!  EXERCISE  UK  HOD  SERIAL  NUMBER  _ 

!  TOP  


TINE  OF  LOSS 
LATITUDE 
LONGITUDE 
IMPLOSION  DEPTH 
WATER  DEPTH 


Special  Keys: 

Previous  Block  <page  up> :  This  will  return  you  to  the 
block  from  which  you  came  (Weapon  or  Target). 

Next  Block  <page  down):  This  will  save  the  data  in  the 
Lost  block  and  move  you  back  to  Attack  (if  the  item 
lost  was  a  weapon),  or  to  the  Unclassified  Comments 
block  (if  the  item  lost  was  a  Target). 

Fiel ds : 


Time  of  Loss:  Enter  the  time  that  the  loss  occurred  in 
standard  date-time  group  format  DDHHMMZ  MONYY .  This 
field  also  has  special  definition  for  the  Previous 
Field  <shift-tab>  key.  If  you  enter  Previous  Field 
<shift-tab>  the  system  assumes  that  you  made  a  mistake 
and  deletes  the  loss  and  moves  you  to  the  block  from 
where  you  came.  If  you  leave  the  field  blank,  you  will 
also  return  to  the  block  from  where  you  came. 

Latitude:    Enter  the  latitude  where  the  loss  occurred. 

Longitude:    Enter  the  Longitude  where  the  loss  occurred. 

Implosion  depth:  Enter  the  depth  at  which  it  imploded,  in 
feet  (if  unknown,  enter  0). 

Water  Depth:  Enter  the  depth  of  the  water  where  the  loss 
occurred  (in  feet).  After  entering  this  field  you  will 
either  return  to  the  Attack  block  or  advance  to  the 
Unclassified  Comments  block. 
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APPENDIX  L 
SAMPLE  REPORTS 

A.     Sample  Brief  Reports 

BRIEF  REPORT 
TITLE  DATE  TIME  LOCATION        BRIEFER 


PRE 
AUD 
PRE 
PRE 
POST 


AUD 

HE 

HERE 

HE 

A122 

HE 

A122 

HE 

12  NAR  1900  IS-300 

HE 

BRIEF  REPORT 
TITLE  DATE  TIME  LOCATION        BRIEFER 


PRESAIL  06  JUN  1100 

PRE 

AUD 

PER-BRIEF 

PREBRIEF         03  MAR  1700 

POST-SAIL 

PRE 

POST 

PRE 

POST 

THESIS 

POST  12  HAR  1900 


AUD 

YOU 

AUD 

HE 

HERE 

HE 

AUD 

HIM 

AUD 

PJD 

SHIP 

DR 

A122 

HE 

1-322 

DR 

A122 

HE 

AUD 

YOU 

HERE 

DJR 

IS-300 

HE 
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B.    Sample  Weekly  Schedule 

WEEKLY  SCHEDULE 


EXERCISE   TITLE 


PERSONNEL   TRACKING     SUPPORT  VEHICLES 
COHEX-FINEX   OPAREA  PE  OC  OA  SO  EATS  I/M  PRIT6T  SECT6T  PRIWEP  8ECMEP 


MONDAY  13  MAR  89 
A612  89082  TORPEX 
A601  89001  TORPEX 


131200-131700  SOAR   A  II   /C  /D 
131900-132200  AREA1    /  /  / 


X   X   TWR   TWR   HC-1   HC-1 
X   X   T    T    H    H 


TUESDAY  14  NAR  89 
A601  89002  TORPEX 
A601  89004  TORPEX 

WEDNESDAY  15  MAR  89 
A612  89083  TORPEX 


140700-141855  AREA1   A  /B  /C  /D 
141300-081600  AREA1    /  /  / 


151400-141800  SOAR   FJ/HN/PD/DR 


X   X   HC1   HC-1   TRW   TMR 
X   X   H         TC    TBY 


X   X   HC-1   TWR   HC-1   TNR 


THURSDAY  16  HAR  89 
A601  89005  TORPEX 


160730-161300  CAST1  WN/RD/TN/RT 


X   X   HC-1   T«R   HC-1   TNR 


FRIDAY  17  MAR  89 

M000  89001  MAINTENANCE 


171230-171700  SOAR   Mfc/M  /  / 
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